* [PATCH v17 05/15] arm64: ptrace: Protect rseq_syscall() from tracer PC modifications
From: Jinjie Ruan @ 2026-07-21 8:18 UTC (permalink / raw)
To: catalin.marinas, will, kees, oleg, luto, wad, thuth, peterz,
mark.rutland, linusw, ada.coupriediaz, kevin.brodsky, yeoreum.yun,
anshuman.khandual, james.morse, tglx, broonie, pengcan,
ryan.roberts, liqiang01, linux-arm-kernel, linux-kernel, linux-mm
Cc: ruanjinjie
In-Reply-To: <20260721081858.1169276-1-ruanjinjie@huawei.com>
Move the rseq_syscall() check earlier in the syscall exit path to ensure
it operates on the original instruction pointer (regs->pc) before any
potential modification by a tracer.
[Background]
When CONFIG_DEBUG_RSEQ is enabled, rseq_syscall() verifies that a system
call was not executed within an rseq critical section by examining
regs->pc. If a violation is detected, it triggers a SIGSEGV.
[Problem]
Currently, arm64 invokes rseq_syscall() after report_syscall_exit().
However, during report_syscall_exit(), a ptrace tracer can modify the
task's instruction pointer via PTRACE_SETREGSET (with NT_PRSTATUS). This
leads to an inconsistency where rseq may analyze a post-trace PC instead
of the actual PC at the time of syscall exit.
[Why this matters]
The rseq check is intended to validate the execution context of the
syscall itself. Analyzing a tracer-modified PC can lead to incorrect
detection or missed violations. Moving the check earlier ensures rseq
sees the authentic state of the task.
[Alignment]
This change aligns arm64 with:
- Generic entry, which calls rseq_syscall() first.
- arm32 implementation, which also performs the check before audit.
[Impact]
There is no functional change to signal delivery; SIGSEGV will still be
processed in arm64_exit_to_user_mode() at the end of the exit path.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@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>
---
arch/arm64/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 4c7dba12629c..a7091333a9e9 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -2511,6 +2511,8 @@ void syscall_trace_exit(struct pt_regs *regs)
unsigned long flags = read_thread_flags();
bool step;
+ rseq_syscall(regs);
+
audit_syscall_exit(regs);
if (flags & _TIF_SYSCALL_TRACEPOINT)
@@ -2519,8 +2521,6 @@ void syscall_trace_exit(struct pt_regs *regs)
step = report_single_step(flags);
if (step || flags & _TIF_SYSCALL_TRACE)
report_syscall_exit(regs);
-
- rseq_syscall(regs);
}
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v17 07/15] arm64: ptrace: Pass thread flags to trace enter/exit
From: Jinjie Ruan @ 2026-07-21 8:18 UTC (permalink / raw)
To: catalin.marinas, will, kees, oleg, luto, wad, thuth, peterz,
mark.rutland, linusw, ada.coupriediaz, kevin.brodsky, yeoreum.yun,
anshuman.khandual, james.morse, tglx, broonie, pengcan,
ryan.roberts, liqiang01, linux-arm-kernel, linux-kernel, linux-mm
Cc: ruanjinjie
In-Reply-To: <20260721081858.1169276-1-ruanjinjie@huawei.com>
Move the reading of thread flags from inside arm64_syscall_trace_enter()
and syscall_trace_exit() to their callers. This aligns the function
signatures with the generic entry framework, where the caller
is responsible for supplying the flags.
In el0_svc_common(), the flags are now passed directly to the tracing
functions, and re-read before the enter/exit path to reflect any updates.
No functional change intended; this is a preparatory step for
converting arm64 to the generic entry infrastructure.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@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>
---
arch/arm64/include/asm/syscall.h | 4 ++--
arch/arm64/kernel/ptrace.c | 6 ++----
arch/arm64/kernel/syscall.c | 11 +++++++----
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index d1dabdcde41c..696739f5a250 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -120,7 +120,7 @@ static inline int syscall_get_arch(struct task_struct *task)
return AUDIT_ARCH_AARCH64;
}
-int arm64_syscall_trace_enter(struct pt_regs *regs);
-void syscall_trace_exit(struct pt_regs *regs);
+int arm64_syscall_trace_enter(struct pt_regs *regs, unsigned long flags);
+void syscall_trace_exit(struct pt_regs *regs, unsigned long flags);
#endif /* __ASM_SYSCALL_H */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index a7091333a9e9..18fa29ae1425 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -2469,9 +2469,8 @@ static inline void syscall_enter_audit(struct pt_regs *regs)
}
#endif
-int arm64_syscall_trace_enter(struct pt_regs *regs)
+int arm64_syscall_trace_enter(struct pt_regs *regs, unsigned long flags)
{
- unsigned long flags = read_thread_flags();
int ret;
if (flags & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) {
@@ -2506,9 +2505,8 @@ static inline bool report_single_step(unsigned long flags)
return flags & _TIF_SINGLESTEP;
}
-void syscall_trace_exit(struct pt_regs *regs)
+void syscall_trace_exit(struct pt_regs *regs, unsigned long flags)
{
- unsigned long flags = read_thread_flags();
bool step;
rseq_syscall(regs);
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index b8d7d29a431b..e778aac6fab9 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -113,7 +113,7 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
*/
if (scno == NO_SYSCALL)
syscall_set_return_value(current, regs, -ENOSYS, 0);
- scno = arm64_syscall_trace_enter(regs);
+ scno = arm64_syscall_trace_enter(regs, read_thread_flags());
if (scno == NO_SYSCALL)
goto trace_exit;
}
@@ -127,13 +127,16 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
*/
if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) {
flags = read_thread_flags();
- if (has_syscall_work(flags) || flags & _TIF_SINGLESTEP)
- syscall_trace_exit(regs);
+ if (has_syscall_work(flags) || flags & _TIF_SINGLESTEP) {
+ flags = read_thread_flags();
+ syscall_trace_exit(regs, flags);
+ }
return;
}
trace_exit:
- syscall_trace_exit(regs);
+ flags = read_thread_flags();
+ syscall_trace_exit(regs, flags);
}
void do_el0_svc(struct pt_regs *regs)
--
2.34.1
^ permalink raw reply related
* [PATCH v17 04/15] arm64: ptrace: Rename and clean up syscall_trace_enter()
From: Jinjie Ruan @ 2026-07-21 8:18 UTC (permalink / raw)
To: catalin.marinas, will, kees, oleg, luto, wad, thuth, peterz,
mark.rutland, linusw, ada.coupriediaz, kevin.brodsky, yeoreum.yun,
anshuman.khandual, james.morse, tglx, broonie, pengcan,
ryan.roberts, liqiang01, linux-arm-kernel, linux-kernel, linux-mm
Cc: ruanjinjie
In-Reply-To: <20260721081858.1169276-1-ruanjinjie@huawei.com>
Rename syscall_trace_enter() to arm64_syscall_trace_enter() to avoid
name collisions and clarify the boundary when arm64 eventually switches
to the generic entry infrastructure.
In addition, replace direct accesses to regs->syscallno with the standard
syscall_get_nr() helper for both trace_sys_enter() and the return value.
This decouples the tracing logic from architecture-specific struct pt_regs
layouts, aligning the implementation with the generic entry pattern.
No functional changes intended; this is a preparation step for
converting arm64 to the generic entry infrastructure.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/include/asm/syscall.h | 2 +-
arch/arm64/kernel/ptrace.c | 6 +++---
arch/arm64/kernel/syscall.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index 5e4c7fc44f73..d1dabdcde41c 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -120,7 +120,7 @@ static inline int syscall_get_arch(struct task_struct *task)
return AUDIT_ARCH_AARCH64;
}
-int syscall_trace_enter(struct pt_regs *regs);
+int arm64_syscall_trace_enter(struct pt_regs *regs);
void syscall_trace_exit(struct pt_regs *regs);
#endif /* __ASM_SYSCALL_H */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index cd0607ec70ef..4c7dba12629c 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -2469,7 +2469,7 @@ static inline void syscall_enter_audit(struct pt_regs *regs)
}
#endif
-int syscall_trace_enter(struct pt_regs *regs)
+int arm64_syscall_trace_enter(struct pt_regs *regs)
{
unsigned long flags = read_thread_flags();
int ret;
@@ -2490,12 +2490,12 @@ int syscall_trace_enter(struct pt_regs *regs)
}
if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
- trace_sys_enter(regs, regs->syscallno);
+ trace_sys_enter(regs, syscall_get_nr(current, regs));
if (unlikely(audit_context()))
syscall_enter_audit(regs);
- return regs->syscallno;
+ return syscall_get_nr(current, regs);
}
static inline bool report_single_step(unsigned long flags)
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index 358ddfbf1401..3e78e159b2a1 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -113,7 +113,7 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
*/
if (scno == NO_SYSCALL)
syscall_set_return_value(current, regs, -ENOSYS, 0);
- scno = syscall_trace_enter(regs);
+ scno = arm64_syscall_trace_enter(regs);
if (scno == NO_SYSCALL)
goto trace_exit;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: arm: add CTCU device for shikra
From: Krzysztof Kozlowski @ 2026-07-21 8:17 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Bjorn Andersson,
Konrad Dybcio, Yuanfang Zhang, Mao Jinlong, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, coresight,
linux-arm-kernel, linux-arm-msm, devicetree, linux-kernel,
linux-riscv
In-Reply-To: <20260715-add-coresight-nodes-for-shikra-v2-1-ebd485e39a51@oss.qualcomm.com>
On Wed, Jul 15, 2026 at 09:16:14AM +0800, Jie Gan wrote:
> The CTCU device for shikra shares the same configurations as SA8775p.
> Add a fallback to enable the CTCU for shikra to utilize the compatible
> of the SA8775p.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 1 +
> 1 file changed, 1 insertion(+)
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
And it should include useful final prefix.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: soc: rockchip: grf: Add RV1106 compatibles
From: Krzysztof Kozlowski @ 2026-07-21 8:16 UTC (permalink / raw)
To: Simon Glass
Cc: Heiko Stuebner, Fabio Estevam, devicetree, Jonas Karlman,
linux-arm-kernel, linux-rockchip, Bartosz Golaszewski,
Conor Dooley, Jeffy Chen, Krzysztof Kozlowski, Michael Riesch,
Rob Herring, Vinod Koul, Yao Zi, huang lin, linux-kernel
In-Reply-To: <20260714193656.2196447-4-sjg@chromium.org>
On Tue, Jul 14, 2026 at 01:36:40PM -0600, Simon Glass wrote:
> Add the compatibles for the general register files of the Rockchip
> RV1106: the main GRF, and the per-bank GPIO IOC blocks used by the pin
> controller.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Drop the grf-cru clock-controller child and use the syscon-only
> group for the main GRF, since the CRU now provides the MMC phase
> clocks
> - Use a single gpio-ioc compatible for the per-bank IOC blocks in
> place of the ioc and pmuioc regions
>
> Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> index 2cc43742b8e3..fd9235ac1334 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -64,6 +64,8 @@ properties:
> - rockchip,rk3588-vo1-grf
> - rockchip,rk3588-vop-grf
> - rockchip,rv1103b-ioc
> + - rockchip,rv1106-gpio-ioc
And this also answers my previous email (pinctrl/gpio bank): you have
one GPIO IOC, not multiple ones, although commit msg tells different
story. Confusing. The compatible here defines register layout (see
writing bindings - it is explicitly documented there) so do you have one
device or multiple with the same register layout?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: gpio: rockchip,gpio-bank: Add rockchip,grf property
From: Krzysztof Kozlowski @ 2026-07-21 8:13 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Heiko Stuebner, Rob Herring, Jonas Karlman,
Conor Dooley, linux-gpio, linux-rockchip, Krzysztof Kozlowski,
linux-arm-kernel, devicetree, Bartosz Golaszewski, linux-kernel
In-Reply-To: <20260714132531.v2.1.d04a89a3849323a0dcee2c701cba43adbb0523b2@changeid>
On Tue, Jul 14, 2026 at 01:25:29PM -0600, Simon Glass wrote:
> Some Rockchip SoCs, such as the RV1106, give each GPIO bank its own
> IO control (IOC) register block rather than grouping the registers of
> all banks into a shared GRF region. Add an optional rockchip,grf
> property to the gpio-bank binding so that each bank node can reference
> the syscon for its own IOC block.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Add new patch for the per-bank IOC reference
>
> .../devicetree/bindings/gpio/rockchip,gpio-bank.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> index bdd83f42615c..774e9c7de606 100644
> --- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> @@ -44,6 +44,13 @@ properties:
> power-domains:
> maxItems: 1
>
> + rockchip,grf:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + The phandle of the syscon node managing the IO control registers
> + of this bank, on SoCs such as the RV1106 where each GPIO bank has
> + its own IOC block.
I do not see usage of it in patchset linked in cover letter with DTS.
I have doubts that whil having one GRF region you have GPIO banks
pointing to different GRF regions.
It's possible if you would have multiple GRFs, but you do not. You have
one GRF, right?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net v2] net: stmmac: resume PHY before hardware setup when opening the interface
From: Paolo Abeni @ 2026-07-21 8:12 UTC (permalink / raw)
To: Maxime Chevallier, Stefan Agner, David S. Miller, Eric Dumazet,
Jakub Kicinski, Andrew Lunn
Cc: Russell King (Oracle), Ovidiu Panait, Maxime Coquelin,
Alexandre Torgue, netdev, linux-stm32, linux-arm-kernel,
regressions
In-Reply-To: <c8cbf359-e224-44c6-8692-9e1d1527ae0c@bootlin.com>
Hi,
On 7/8/26 11:16 AM, Maxime Chevallier wrote:
> On 7/7/26 21:54, Stefan Agner wrote:
>> Since the referenced commit, changing the MTU on a running interface no
>> longer disconnects and reconnects the PHY; __stmmac_release() merely
>> stops phylink, which also suspends the PHY (BMCR power-down) when WoL
>> is not enabled. __stmmac_open() then performs the DMA software reset in
>> stmmac_hw_setup() before phylink_start() resumes the PHY again.
>>
>> IEEE 802.3 22.2.4.1.5 allows a PHY to stop its receive clock while
>> powered down, and stmmac requires a running receive clock for the DMA
>> software reset to complete (the phylink config sets mac_requires_rxc).
>> On such setups, e.g. the RK3566-based Home Assistant Green with an
>> RTL8211F-VD PHY in RGMII mode, any runtime MTU change now times out and
>> leaves the interface dead:
>>
>> rk_gmac-dwmac fe010000.ethernet end0: Failed to reset the dma
>> rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed
>> rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed
>> rk_gmac-dwmac fe010000.ethernet end0: failed reopening the interface after MTU change
>>
>> In the field this is triggered by NetworkManager applying an MTU while
>> activating the connection, breaking networking entirely.
>>
>> Resume the PHY in __stmmac_open() before the hardware setup, making it
>> the counterpart of the phylink_stop() in __stmmac_release(), like
>> stmmac_resume() already does for the same reason. phylink_start() also
>> resumes the PHY, but only after stmmac_hw_setup(), and it cannot be
>> moved before the hardware setup since it may bring the link up
>> immediately from a workqueue, racing with the initialization (see the
>> comment in stmmac_resume()). For the regular ndo_open path the PHY has
>> just been attached and is not suspended, in which case
>> phylink_prepare_resume() does nothing.
>>
>> Fixes: db299a0c09e9 ("net: stmmac: move PHY handling out of __stmmac_open()/release()")
>> Link: https://github.com/home-assistant/operating-system/issues/4858
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>
> I was able to reproduce the issue on imx8mp and socfpga. Adding this case to
> my periodic test list...
>
> Indeed the assymetry isn't very nice, OTOH there's not phylink counterpart
> for phylink_prepare_resume(). This helper was added for the suspend/resume
> case, and only for it as the doc states, it just happens to do exactly
> what we need to fix the issue :
>
> /**
> * phylink_prepare_resume() - prepare to resume a network device
> * @pl: a pointer to a &struct phylink returned from phylink_create()
> *
> * Optional, but if called must be called prior to phylink_resume().
> *
> * Prepare to resume a network device, preparing the PHY as necessary.
> */
> void phylink_prepare_resume(struct phylink *pl)
>
> I think this helper should be renamed and the doc updated, stmmac is the
> sole user, and it's really about controlling that rxc and not about
> suspend / resume. Resuming from suspend is just one of the cases where we
> need that RXC early on.
>
> So either something like 'phylink_prepare_start_or_resume' but it's long,
> or maybe we can be more explicit about it and simply call it:
>
> phylink_start_rxc(pl)
>
> (without a corresponding stop)
I read the above as a possible follow-up more than actual changes
requested to this patch, am I correct?
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: serial: snps-dw-apb-uart: Add RV1106 compatible
From: Krzysztof Kozlowski @ 2026-07-21 8:10 UTC (permalink / raw)
To: Simon Glass
Cc: Greg Kroah-Hartman, Jiri Slaby, Heiko Stuebner,
Krzysztof Kozlowski, Conor Dooley, Rob Herring, devicetree,
linux-rockchip, linux-serial, linux-arm-kernel, linux-kernel
In-Reply-To: <20260714132035.v2.1.c1d92213393f49330ec14d0c670a802181b4fcbf@changeid>
On Tue, Jul 14, 2026 at 01:20:36PM -0600, Simon Glass wrote:
> Add the compatible for the UARTs of the Rockchip RV1106, which are
> compatible with the Synopsys DesignWare APB UART.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next] net: sparx5: configure TAS port link speed
From: patchwork-bot+netdevbpf @ 2026-07-21 8:10 UTC (permalink / raw)
To: Robert Marko
Cc: daniel.machon, UNGLinuxDriver, andrew+netdev, davem, edumazet,
kuba, pabeni, Steen.Hegelund, horms, netdev, linux-arm-kernel,
linux-kernel, luka.perkov
In-Reply-To: <20260707170531.1129866-1-robert.marko@sartura.hr>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 7 Jul 2026 19:04:48 +0200 you wrote:
> On the TSN and RED variants of LAN969x and SparX-5i TAS (Time-Aware Shaper)
> is present in the silicon.
>
> Currently, the driver does not use configure it at all, which means that
> the TAS_PROFILE_CONFIG.LINK_SPEED[1] value is left at the default of 3
> which means that its configured for 1 Gbps.
>
> [...]
Here is the summary with links:
- [net-next] net: sparx5: configure TAS port link speed
https://git.kernel.org/netdev/net-next/c/80d8e1d428e8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v5 0/5] clock: versal-clk: Fix Versal NET clock binding and switch to CCF
From: Michal Simek @ 2026-07-21 8:09 UTC (permalink / raw)
To: linux-kernel, monstr, git
Cc: Brian Masney, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Rob Herring, Shubhrajyoti Datta, Stephen Boyd,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
kishore Manne, moderated list:ARM/ZYNQ ARCHITECTURE,
open list:COMMON CLK FRAMEWORK
In-Reply-To: <cover.1783516336.git.michal.simek@amd.com>
On 7/8/26 15:12, Michal Simek wrote:
> This series fixes the Versal NET clock controller DT binding validation
> and switches the platform to use the firmware-based CCF clock interface.
>
> One patch extracts zynqmp to own DT binding file.
>
> Another restructures the if/then conditions in the versal-clk binding
> schema so that xlnx,versal-net-clk is matched first before falling back
> to xlnx,versal-clk. This fixes false "too long" validation errors caused
> by both conditions matching simultaneously when the fallback compatible
> is present. A dedicated example for the Versal NET 3-clock configuration
> is added and all examples are split into separate blocks for independent
> validation.
>
> The last patch switches Versal NET from static fixed-clock definitions to
> the firmware-based clock interface, enabling proper clock management
> through platform firmware. DT macro headers for clocks, power domains
> and resets are added.
>
> Thanks,
> Michal
>
> Changes in v5:
> - update commit message s/zynqmp-clk/versal-clk/
> - Also update firmware node to match xlnx,versal-firmware enforced by
> schema (change taken from next patch)
> - Update commit message
> - Move change done in v4 to previous patch where issue started.
>
> Changes in v4:
> - simplify expression to [0-6][0-9] from 0[0-9||[1-6][0-9]
> - Update regex from previous patch
> - Also update firmware node to match xlnx,versal-firmware enforced by
> schema
>
> Changes in v3:
> - new patch in series
> - New patch in series
> - Cover change in zynqmp-firmware.yaml
> - Move clock-cells to be the last in the example
> - Remove comment around (Optional clock) which is obvious from schema
> itself
> - Move clock-cells to be the last property in the example
> - use 2 spaces for indentation in example to follow the same style which is
> already used
> - Add fixed tag
> - Remove interrupt from zynqmp-power - Versal NET is using event framework
> instead. No interrupt is required.
> - Remove unused GEM{0,1}_REF_{R,T}X macros
> - Update commit message
> - s/zynqmp/versal-net/ in subject
> - Update copyrights
> - Make all macro values lower case
> - Fix guarding macro names
>
> Changes in v2:
> - New patch in series
> - Split zynqmp-clk from versal-clk
> - Update logic without ZynqMP part in this file and have if/else only
> around min/maxItems
> - use clock-<HZ> node name for fixed clocks
> - Reuse existing versal-net-clk.dtsi file
>
> Michal Simek (5):
> dt-bindings: firmware: xilinx: Add missing example for ZynqMP
> dt-bindings: clock: versal-clk: Fix mio_clk index range in clock-names
> pattern
> dt-bindings: clock: Move xlnx,zynqmp-clk to its own schema
> dt-bindings: clock: versal-clk: Fix Versal NET clock validation
> arm64: versal-net: Switch Versal NET to firmware clock interface
>
> .../bindings/clock/xlnx,versal-clk.yaml | 93 ++---
> .../bindings/clock/xlnx,zynqmp-clk.yaml | 68 ++++
> .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 15 +-
> .../arm64/boot/dts/xilinx/versal-net-clk.dtsi | 345 +++++++++++++-----
> arch/arm64/boot/dts/xilinx/xlnx-versal-clk.h | 123 +++++++
> .../boot/dts/xilinx/xlnx-versal-net-clk.h | 74 ++++
> .../boot/dts/xilinx/xlnx-versal-net-power.h | 38 ++
> .../boot/dts/xilinx/xlnx-versal-net-resets.h | 53 +++
> .../arm64/boot/dts/xilinx/xlnx-versal-power.h | 55 +++
> .../boot/dts/xilinx/xlnx-versal-resets.h | 106 ++++++
> 10 files changed, 797 insertions(+), 173 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.yaml
> create mode 100644 arch/arm64/boot/dts/xilinx/xlnx-versal-clk.h
> create mode 100644 arch/arm64/boot/dts/xilinx/xlnx-versal-net-clk.h
> create mode 100644 arch/arm64/boot/dts/xilinx/xlnx-versal-net-power.h
> create mode 100644 arch/arm64/boot/dts/xilinx/xlnx-versal-net-resets.h
> create mode 100644 arch/arm64/boot/dts/xilinx/xlnx-versal-power.h
> create mode 100644 arch/arm64/boot/dts/xilinx/xlnx-versal-resets.h
>
> ---
> base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
> branch: xnext/versal-net
>
Applied.
M
^ permalink raw reply
* [PATCH] dt-bindings: usb: mtu3: Add MT8512
From: Carlo Caione @ 2026-07-21 8:00 UTC (permalink / raw)
To: Chunfeng Yun, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-usb, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel, David Lechner, Julien Stephan, Carlo Caione
The MT8512 USB controller uses the standard MTU3 device MAC and IPPC
register layout and is handled by the generic mediatek,mtu3 driver. Add
the SoC-specific compatible so the controller can be described without a
legacy split node.
For now the only user of this is on the U-Boot side but we want to keep
bindings in sync.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
---
Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
index 21fc6bbe954f..42da2c6dfba1 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
@@ -29,6 +29,7 @@ properties:
- mediatek,mt8192-mtu3
- mediatek,mt8195-mtu3
- mediatek,mt8365-mtu3
+ - mediatek,mt8512-mtu3
- const: mediatek,mtu3
reg:
---
base-commit: b95f03f04d475aa6719d15a636ddf32222d55657
change-id: 20260721-ccaione-upstream-mt8512-mtu3-binding-50165b8c8171
Best regards,
--
Carlo Caione <ccaione@baylibre.com>
^ permalink raw reply related
* Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-21 7:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andi Shyti,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Andy Shevchenko,
Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Lee Jones, Sebastian Hesselbarth,
Srinivas Kandagatla, driver-core, linuxppc-dev, linux-kernel,
linux-i2c, iommu, netdev, linux-pm, imx, linux-arm-kernel, mfd,
linux-arm-msm, linux-sound, Bartosz Golaszewski
In-Reply-To: <3e14e41f-ecd5-432b-9f52-690a05b38a8a@lunn.ch>
On Mon, 20 Jul 2026 20:28:39 +0200, Andrew Lunn <andrew@lunn.ch> said:
> On Mon, Jul 20, 2026 at 06:01:37PM +0200, Bartosz Golaszewski wrote:
>> On Mon, 20 Jul 2026 16:43:40 +0200, Andrew Lunn <andrew@lunn.ch> said:
>> > On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote:
>> >> Prefer the higher-level platform_device_set_fwnode() over the
>> >> OF-specific platform_device_set_of_node() for dynamically allocated
>> >> platform devices.
>> >>
>> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> >> ---
>> >> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
>> >> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>> >> goto put_err;
>> >> }
>> >> ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> >> - platform_device_set_of_node(ppdev, pnp);
>> >> + platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
>> >
>> > This is definitely an OF only driver. There are no other calls to
>> > fwnode functions in this driver, so this is the wrong thing to do.
>> >
>> > Sorry, NACK.
>> >
>>
>> I'm not going to die on this hill but drivers are OF-only until they're not.
>> For example, Qualcomm is now working on a hybrid ACPI-OF approach for
>> laptops[1] and we may end up needing to start converting drivers to fwnode
>> after all.
>>
>> There's no real benefit to sticking to OF-specific APIs unless you need to
>> iterate over all properties of a node or use some other functionality not
>> available in fwnode. The overhead is minimal and it's never a hot path.
>
> There is a lot of benefit to sticking to OF specific APIs, because
> within the kernel OF is well maintained, has active maintainers, there
> are tools to validate bindings, etc. ACPI is a Wild West, each driver
> is a snow flake, there is no review, no binding documentation, no
> validation tools etc.
>
> I hope you allow plenty of time to convert any networking drivers,
> where Linux is driving the hardware, to ACPI. Your first stop will be
> the UEFI forum making a proposal for MDIO busses, because that
> currently is not part of ACPI. You will then need to spend time
> understanding the DT bindings, and figuring out which properties are
> deprecated so need to stay OF only, and which can be converted to dual
> OF/ACPI. I've seen too many naive attempts which blindly convert
> everything, copying all the past errors in the DT binding into the
> brand new ACPI binding. That will get NACKed.
>
> OF != ACPI
>
I've never said that and ACPI is actually irrelevant to this discussion. Fwnode
is the abstraction layer and OF happens to implement it. Unless you need
fine-grained control (only exposed by the lower-level abstraction) or
performance - neither of which is the case here - you should use the top-level
API. As I said: there's no good reason to stick to OF-specific interfaces for
drivers that don't really require it - and even then, we should strive to fill
the gaps in the fwnode API instead.
Bart
^ permalink raw reply
* Re: [PATCH v3] ARM: traps: Implement KCFI trap handler for ARM32
From: Linus Walleij @ 2026-07-21 7:54 UTC (permalink / raw)
To: Kees Cook
Cc: Russell King (Oracle), Nathan Chancellor, Sami Tolvanen, Zhen Lei,
Arnd Bergmann, Michał Pecio, Sebastian Andrzej Siewior,
linux-arm-kernel, Russell King, Will Deacon, Mark Rutland,
Nick Desaulniers, Bill Wendling, Justin Stitt, linux-kernel, llvm,
linux-hardening
In-Reply-To: <20260715175223.make.153-kees@kernel.org>
On Wed, Jul 15, 2026 at 7:52 PM Kees Cook <kees@kernel.org> wrote:
> ARM32 GCC KCFI[1] violations currently show as generic "Oops - undefined
> instruction" errors, making debugging CFI failures difficult. Add a proper
> KCFI trap handler similar to the aarch64 implementation to provide clear
> CFI error messages, including the call target and the expected type.
Reviewed-by: Linus Walleij <linusw@kernel.org>
> Clang and GCC trap CFI failures differently on ARM32. Clang lowers
> its checks to a BKPT, handled via the breakpoint/prefetch-abort path
> in hw_breakpoint.c, which cannot recover the target or expected type
> and so must report via report_cfi_failure_noaddr(). GCC instead lowers
> KCFI checks to a UDF (undefined instruction) whose immediate encodes
> the registers involved, so the handler can decode it and call the full
> report_cfi_failure() with the target and expected type.
Aha, that explains a few things.
The UDF is a better approach for ARM I think (Russell will know best).
As noted from earlier conversation the breakpoint usecase overloading
on ARM is a mess, and we would certainly like to avoid it if possible,
albeit I have a patch in Russell's patch tracker to paper it over.
Do you think that long term we could switch Clang to do what
GCC does?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 9/9] arm64: dts: mediatek: mt8192-asurada-spherion: Add Synaptics trackpad's supply
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel, stable+noautosel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
The Synaptics trackpad, like the Elan trackpad option, is fed from the
system 3.3V power rail. Add it to the trackpad device node.
Also add the correct post-power-on delay, even though in practice it is
not required. The Synaptics trackpad requires 100ms after power-on (or
deasserting the reset, whichever comes later) to fully initialize. The
power is always on and the reset pin is not routed out, so the
implementation could try skipping the delay.
Cc: <stable+noautosel@kernel.org> # Without driver changes only lengthens probe time
Fixes: 925ebc0cd55c ("arm64: dts: mt8192-asurada-spherion: Add Synaptics trackpad support")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
I think this shouldn't be backported, as backporting it without the
driver enhancements just delays the trackpad probing with no real
gains.
---
arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts b/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts
index 68caf4c58cfe..8adbfc307fca 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts
@@ -94,6 +94,8 @@ trackpad@2c {
hid-descr-addr = <0x20>;
interrupts-extended = <&pio 15 IRQ_TYPE_LEVEL_LOW>;
wakeup-source;
+ vdd-supply = <&pp3300_u>;
+ post-power-on-delay-ms = <100>;
status = "fail-needs-probe";
};
};
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 7/9] platform/chrome: of_hw_prober: Add delay for hana trackpads
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
Up until now, the MT8173 elm/hana device tree has set the dedicated
regulator supplying the trackpad as always-on, simply because the Elan
driver was missing proper delays. As a result the delay for the
Synaptics trackpad was also omitted, as it was not strictly required
under such a model and delayed the availability of the trackpad to the
user.
The Elan driver recently gained proper delays after power-up, with
adaptive skipping of the delay if the regulator was originally
on. The I2C HID driver and I2C OF component prober library gained
similar adaptive delay skipping. The device tree will be fixed to have
the regulator not be always on, and proper post-power-on delay time
added to the I2C HID device.
Also add the post-power-on delay to the ChromeOS OF component prober,
so that if the regulator is off at the time of probing, the prober knows
to wait for the hardware to initialize.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/platform/chrome/chromeos_of_hw_prober.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/platform/chrome/chromeos_of_hw_prober.c b/drivers/platform/chrome/chromeos_of_hw_prober.c
index 8562a0e89dc6..54d8941617e2 100644
--- a/drivers/platform/chrome/chromeos_of_hw_prober.c
+++ b/drivers/platform/chrome/chromeos_of_hw_prober.c
@@ -70,10 +70,8 @@ static const struct chromeos_i2c_probe_data chromeos_i2c_probe_hana_trackpad = {
/*
* ELAN trackpad needs 2 ms for H/W init and 100 ms for F/W init.
* Synaptics trackpad needs 100 ms.
- * However, the regulator is set to "always-on", presumably to
- * avoid this delay. The ELAN driver is also missing delays.
*/
- .post_power_on_delay_ms = 0,
+ .post_power_on_delay_ms = 110,
},
};
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 8/9] arm64: dts: mediatek: mt8173-elm-hana: Unmark trackpad supply as always-on
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
Up until now, the MT8173 elm/hana device tree has set the dedicated
regulator supplying the trackpad as always-on, simply because the Elan
driver was missing proper delays. As a result the delay for the
Synaptics trackpad was also omitted, as it was not strictly required
under such a model and delayed the availability of the trackpad to the
user.
The Elan driver recently gained proper delays after power up, with
opportunistic skipping of the delay when the regulator was originally
on. The I2C HID driver gained similar opportunistic delay skipping.
So has the I2C OF component prober library.
Now fix the device tree to have the regulator not be always on, and
let the I2C HID device have the correct post-power-on delay time.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi | 8 +-------
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 -
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
index 1004eb8ea52c..b9e311fcd9a0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
@@ -62,13 +62,7 @@ trackpad2: trackpad@2c {
pinctrl-0 = <&trackpad_irq>;
reg = <0x2c>;
hid-descr-addr = <0x0020>;
- /*
- * The trackpad needs a post-power-on delay of 100ms,
- * but at time of writing, the power supply for it on
- * this board is always on. The delay is therefore not
- * added to avoid impacting the readiness of the
- * trackpad.
- */
+ post-power-on-delay-ms = <100>;
vdd-supply = <&mt6397_vgp6_reg>;
wakeup-source;
status = "fail-needs-probe";
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index a0573bc359fb..6b9f47f515c7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -1093,7 +1093,6 @@ mt6397_vgp6_reg: ldo_vgp6 {
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-enable-ramp-delay = <218>;
- regulator-always-on;
};
mt6397_vibr_reg: ldo_vibr {
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 6/9] i2c: of-prober: Defer regulator_disable() on successful probe in simple helper
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
When a I2C component is found, it's device node is immediately enabled.
This triggers device creation and driver binding. The prober will hold
the regulator enable reference across this part. If the driver probes
synchronously, then it happens within this window. On the other hand,
if the driver probes asynchronously, there is high chance that it
happens after the prober's cleanup function was called, in which case
the regulator would have been disabled when the driver's probe function
is called. This would then require the driver to wait 100 ms for the
hardware to reinitialize, even if the probe function was just a split
second late and the regulator was disabled a few milliseconds ago.
Recently, some of the drivers for the component that are targeted by the
I2C OF component prober gained the ability to skip waiting for hardware
initialization if the regulator was left enabled. This happens when the
PMIC has them on by default, or if the component prober left them on
after probing the component.
Wait a bit of time before dropping the enable refcount on our end so
that the actual driver has the opportunity to catch and increase the
refcount on their end. The 100 ms delay was arbitrarily chosen.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/i2c/i2c-core-of-prober.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c-core-of-prober.c b/drivers/i2c/i2c-core-of-prober.c
index f9f3c0ef93ff..68c929b16b06 100644
--- a/drivers/i2c/i2c-core-of-prober.c
+++ b/drivers/i2c/i2c-core-of-prober.c
@@ -235,11 +235,23 @@ static int i2c_of_probe_simple_enable_regulator(struct device *dev, struct i2c_o
return 0;
}
-static void i2c_of_probe_simple_disable_regulator(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
+static void i2c_of_probe_simple_disable_regulator(struct device *dev,
+ struct i2c_of_probe_simple_ctx *ctx,
+ bool defer_disable)
{
if (!ctx->supply)
return;
+ /*
+ * Wait a bit of time for async drivers to probe and increase the
+ * regulator enable count. This allows the drivers to check and
+ * skip waiting for re-initialization.
+ */
+ if (defer_disable) {
+ dev_dbg(dev, "Deferring regulator disable\n");
+ msleep(100);
+ }
+
dev_dbg(dev, "Disabling regulator supply \"%s\"\n", ctx->opts->supply_name);
regulator_disable(ctx->supply);
@@ -356,7 +368,7 @@ int i2c_of_probe_simple_enable(struct device *dev, struct device_node *bus_node,
return 0;
out_disable_regulator:
- i2c_of_probe_simple_disable_regulator(dev, ctx);
+ i2c_of_probe_simple_disable_regulator(dev, ctx, false);
out_put_gpiod:
i2c_of_probe_simple_put_gpiod(ctx);
out_put_supply:
@@ -401,7 +413,7 @@ void i2c_of_probe_simple_cleanup(struct device *dev, void *data)
i2c_of_probe_simple_disable_gpio(dev, ctx);
i2c_of_probe_simple_put_gpiod(ctx);
- i2c_of_probe_simple_disable_regulator(dev, ctx);
+ i2c_of_probe_simple_disable_regulator(dev, ctx, true);
i2c_of_probe_simple_put_supply(ctx);
}
EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_cleanup, "I2C_OF_PROBER");
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 5/9] i2c: of-prober: skip post-power-on delay if powered on sufficiently long
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
On some devices the I2C component is powered from an always-on power
rail, or the power rail has been left on by either POR defaults or
the bootloader. By the time the prober probes the device, the device
most certainly has finished initializing and can respond. There is no
need for the delay.
In such designs, the system integrators tend to work around the delay
to avoid the boot time penalty by simply omitting it from the device
tree and the component prober. This is undesired, as the device tree
is not fully describing the hardware.
Switch to the new regulator_enable_and_wait() function that makes sure
a certain amount of time has passed since the regulator supply was
actually enabled.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- Switched to new regulator_enable_and_wait() API
---
drivers/i2c/i2c-core-of-prober.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/i2c-core-of-prober.c b/drivers/i2c/i2c-core-of-prober.c
index 6a82b03809d4..f9f3c0ef93ff 100644
--- a/drivers/i2c/i2c-core-of-prober.c
+++ b/drivers/i2c/i2c-core-of-prober.c
@@ -18,6 +18,7 @@
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/stddef.h>
+#include <linux/time.h>
/*
* Some devices, such as Google Hana Chromebooks, are produced by multiple
@@ -226,13 +227,11 @@ static int i2c_of_probe_simple_enable_regulator(struct device *dev, struct i2c_o
dev_dbg(dev, "Enabling regulator supply \"%s\"\n", ctx->opts->supply_name);
- ret = regulator_enable(ctx->supply);
+ ret = regulator_enable_and_wait(ctx->supply,
+ ctx->opts->post_power_on_delay_ms * USEC_PER_MSEC);
if (ret)
return ret;
- if (ctx->opts->post_power_on_delay_ms)
- msleep(ctx->opts->post_power_on_delay_ms);
-
return 0;
}
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 4/9] HID: i2c-hid-of: skip post-power-on delay if powered on sufficiently long
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
On some devices the HID device is powered from an always-on power rail,
or the power rail has been left on by either POR defaults or the
bootloader. By the time the driver probes, the device most certainly
has finished initializing. There is no need for the delay.
In such designs, the system integrators tend to work around the delay
to avoid the boot time penalty by simply omitting it from the device
tree. This is undesired, as the device tree is not fully describing
the hardware.
Switch to the new regulator_bulk_enable_and_wait() function that makes
sure a certain amount of time has passed since the regulator supplies
were actually enabled.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- Switched to new regulator_bulk_enable_and_wait() API
---
drivers/hid/i2c-hid/i2c-hid-of.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
index 59393d71ddb9..fdaad451e710 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -29,6 +29,7 @@
#include <linux/of.h>
#include <linux/pm.h>
#include <linux/regulator/consumer.h>
+#include <linux/time.h>
#include "i2c-hid.h"
@@ -48,16 +49,14 @@ static int i2c_hid_of_power_up(struct i2chid_ops *ops)
struct device *dev = &ihid_of->client->dev;
int ret;
- ret = regulator_bulk_enable(ARRAY_SIZE(ihid_of->supplies),
- ihid_of->supplies);
+ ret = regulator_bulk_enable_and_wait(ARRAY_SIZE(ihid_of->supplies),
+ ihid_of->supplies,
+ ihid_of->post_power_delay_ms * USEC_PER_MSEC);
if (ret) {
dev_warn(dev, "Failed to enable supplies: %d\n", ret);
return ret;
}
- if (ihid_of->post_power_delay_ms)
- msleep(ihid_of->post_power_delay_ms);
-
gpiod_set_value_cansleep(ihid_of->reset_gpio, 0);
if (ihid_of->post_reset_delay_ms)
msleep(ihid_of->post_reset_delay_ms);
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 3/9] Input: elan_i2c - Wait for initialization after enabling regulator supply
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
Elan trackpad controllers require some delay after enabling power to
the controller for the hardware and firmware to initialize:
- 2ms for hardware initialization
- 100ms for firmware initialization
Until then, the hardware will not respond to I2C transfers. This was
observed on the MT8173 Chromebooks after the regulator supply for the
trackpad was changed to "not always on".
Switch to the new regulator_enable_and_wait(). This makes sure that
enough time has passed since the regulator was first enabled, satisfying
the power sequencing delay requirement. This allows the delay to be
skipped if the regulator supply was already enabled by some other part
of the kernel, such as the I2C OF component prober.
Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- Switched to new regulator_enable_and_wait() API
Changes since v1:
- Delay only if the regulator was previously disabled / turned off
- Link to v1
https://lore.kernel.org/all/20241001093815.2481899-1-wenst@chromium.org/
---
drivers/input/mouse/elan_i2c_core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index 9f024a435dbf..77885930bf9e 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -36,6 +36,7 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/string_choices.h>
+#include <linux/time.h>
#include <linux/uaccess.h>
#include <linux/unaligned.h>
@@ -47,6 +48,8 @@
#define ETP_FWIDTH_REDUCE 90
#define ETP_FINGER_WIDTH 15
#define ETP_RETRY_COUNT 3
+/* H/W init 2 ms + F/W init 100 ms w/ round up */
+#define ETP_POWER_ON_DELAY_US (110 * USEC_PER_MSEC)
/* quirks to control the device */
#define ETP_QUIRK_QUICK_WAKEUP BIT(0)
@@ -1250,7 +1253,7 @@ static int elan_probe(struct i2c_client *client)
if (IS_ERR(data->vcc))
return dev_err_probe(dev, PTR_ERR(data->vcc), "Failed to get 'vcc' regulator\n");
- error = regulator_enable(data->vcc);
+ error = regulator_enable_and_wait(data->vcc, ETP_POWER_ON_DELAY_US);
if (error) {
dev_err(dev, "Failed to enable regulator: %d\n", error);
return error;
@@ -1406,7 +1409,7 @@ static int elan_resume(struct device *dev)
int error;
if (!device_may_wakeup(dev)) {
- error = regulator_enable(data->vcc);
+ error = regulator_enable_and_wait(data->vcc, ETP_POWER_ON_DELAY_US);
if (error) {
dev_err(dev, "error %d enabling regulator\n", error);
goto err;
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 2/9] Input: elan_i2c - sort include statements
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
Sort the include statements before adding new ones in the next change.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- New patch
---
drivers/input/mouse/elan_i2c_core.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index f93dd545d66b..9f024a435dbf 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -16,27 +16,27 @@
*/
#include <linux/acpi.h>
+#include <linux/completion.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/firmware.h>
#include <linux/i2c.h>
#include <linux/init.h>
+#include <linux/input.h>
#include <linux/input/mt.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
-#include <linux/module.h>
-#include <linux/slab.h>
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/string_choices.h>
-#include <linux/input.h>
-#include <linux/uaccess.h>
#include <linux/jiffies.h>
-#include <linux/completion.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/pm_wakeirq.h>
#include <linux/property.h>
#include <linux/regulator/consumer.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/string_choices.h>
+#include <linux/uaccess.h>
#include <linux/unaligned.h>
#include "elan_i2c.h"
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 1/9] regulator: core: Add "enable and wait" functions
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
In-Reply-To: <20260721075226.2347933-1-wenst@chromium.org>
In device power sequencing and initialization use cases, it is common
for the driver to enable the regulator and then wait for a certain
period of time to pass before continuing.
In cases where the regulator supply is always on, or has been turned on
or left on by another consumer, the driver could shorten the delay or
skip it altogether, provided that enough time has already passed since
the regulator was _actually_ turned on.
Tracking this requires support from the regulator core. Introduce a
"last turned on" timestamp field to the regulator device, and "enable
and wait" functions to the single and bulk regulator consumer APIs.
The existing "enable without wait" functions are then converted to
macros that expand to the new functions.
One case in particular is not optimized yet: a regulator left on either
by hardware reset default or by the bootloader, but does not have the
"regulator-boot-on" property set. As the enable timestamp only gets
updated when enabled by a consumer or by the core, the first enablement
always needs to wait.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- New patch
---
drivers/regulator/core.c | 53 ++++++++++++++++++++++--------
include/linux/regulator/consumer.h | 21 ++++++++----
include/linux/regulator/driver.h | 2 ++
3 files changed, 57 insertions(+), 19 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 1797929dfe56..d14ce86d8f7b 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -98,7 +98,8 @@ struct regulator_event_work {
unsigned long event;
};
-static int _regulator_enable(struct regulator *regulator);
+static int _regulator_enable_and_wait(struct regulator *regulator, unsigned int wait_us);
+#define _regulator_enable(regulator) _regulator_enable_and_wait(regulator, 0)
static int _regulator_is_enabled(struct regulator_dev *rdev);
static int _regulator_disable(struct regulator *regulator);
static int _regulator_get_error_flags(struct regulator_dev *rdev, unsigned int *flags);
@@ -3043,6 +3044,8 @@ static int _regulator_do_enable(struct regulator_dev *rdev)
fsleep(delay);
}
+ rdev->last_on = ktime_get_boottime();
+
trace_regulator_enable_complete(rdev_get_name(rdev));
return 0;
@@ -3112,8 +3115,8 @@ static int _regulator_handle_consumer_disable(struct regulator *regulator)
return 0;
}
-/* locks held by regulator_enable() */
-static int _regulator_enable(struct regulator *regulator)
+/* locks held by regulator_enable_and_wait() */
+static int _regulator_enable_and_wait(struct regulator *regulator, unsigned int wait_us)
{
struct regulator_dev *rdev = regulator->rdev;
int ret;
@@ -3159,13 +3162,24 @@ static int _regulator_enable(struct regulator *regulator)
} else if (ret < 0) {
rdev_err(rdev, "is_enabled() failed: %pe\n", ERR_PTR(ret));
goto err_consumer_disable;
+ } else {
+ /* regulator already enabled somehow, but timestamp might be invalid */
+ if (!rdev->last_on)
+ rdev->last_on = ktime_get_boottime();
}
- /* Fallthrough on positive return values - already enabled */
}
if (regulator->enable_count == 1)
rdev->use_count++;
+ if (wait_us) {
+ ktime_t end = ktime_add_us(rdev->last_on, wait_us);
+ s64 remaining = ktime_us_delta(end, ktime_get_boottime());
+
+ if (remaining > 0)
+ fsleep(remaining);
+ }
+
return 0;
err_consumer_disable:
@@ -3179,31 +3193,36 @@ static int _regulator_enable(struct regulator *regulator)
}
/**
- * regulator_enable - enable regulator output
+ * regulator_enable_and_wait - enable regulator output and wait for time
+ * passed after regulator actually enabled
* @regulator: regulator source
+ * @wait_us: time to wait after regulator actually turned on; 0 to not wait
*
* Request that the regulator be enabled with the regulator output at
* the predefined voltage or current value. Calls to regulator_enable()
* must be balanced with calls to regulator_disable().
*
+ * If wait_us is greater than zero, then check that wait_us has passed since
+ * the regulator is _actually_ enabled before returning.
+ *
* NOTE: the output value can be set by other drivers, boot loader or may be
* hardwired in the regulator.
*
* Return: 0 on success or a negative error number on failure.
*/
-int regulator_enable(struct regulator *regulator)
+int regulator_enable_and_wait(struct regulator *regulator, unsigned int wait_us)
{
struct regulator_dev *rdev = regulator->rdev;
struct ww_acquire_ctx ww_ctx;
int ret;
regulator_lock_dependent(rdev, &ww_ctx);
- ret = _regulator_enable(regulator);
+ ret = _regulator_enable_and_wait(regulator, wait_us);
regulator_unlock_dependent(rdev, &ww_ctx);
return ret;
}
-EXPORT_SYMBOL_GPL(regulator_enable);
+EXPORT_SYMBOL_GPL(regulator_enable_and_wait);
static int _regulator_do_disable(struct regulator_dev *rdev)
{
@@ -5372,30 +5391,38 @@ static void regulator_bulk_enable_async(void *data, async_cookie_t cookie)
{
struct regulator_bulk_data *bulk = data;
- bulk->ret = regulator_enable(bulk->consumer);
+ bulk->ret = regulator_enable_and_wait(bulk->consumer, bulk->wait_us);
}
/**
- * regulator_bulk_enable - enable multiple regulator consumers
+ * regulator_bulk_enable_and_wait - enable multiple regulator consumers and
+ * wait for time passed after regulators are
+ * actually enabled
*
* @num_consumers: Number of consumers
* @consumers: Consumer data; clients are stored here.
+ * @wait_us: time to wait after regulators actually turned on; 0 to not wait
*
* This convenience API allows consumers to enable multiple regulator
* clients in a single API call. If any consumers cannot be enabled
* then any others that were enabled will be disabled again prior to
* return.
*
+ * If wait_us is greater than zero, then check that wait_us has passed since
+ * the regulators are _actually_ enabled before returning.
+ *
* Return: 0 on success or a negative error number on failure.
*/
-int regulator_bulk_enable(int num_consumers,
- struct regulator_bulk_data *consumers)
+int regulator_bulk_enable_and_wait(int num_consumers,
+ struct regulator_bulk_data *consumers,
+ unsigned int wait_us)
{
ASYNC_DOMAIN_EXCLUSIVE(async_domain);
int i;
int ret = 0;
for (i = 0; i < num_consumers; i++) {
+ consumers[i].wait_us = wait_us;
async_schedule_domain(regulator_bulk_enable_async,
&consumers[i], &async_domain);
}
@@ -5423,7 +5450,7 @@ int regulator_bulk_enable(int num_consumers,
return ret;
}
-EXPORT_SYMBOL_GPL(regulator_bulk_enable);
+EXPORT_SYMBOL_GPL(regulator_bulk_enable_and_wait);
/**
* regulator_bulk_disable - disable multiple regulator consumers
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index 56fe2693d9b2..a69157c9b5b5 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -145,6 +145,7 @@ struct regulator_bulk_data {
/* private: Internal use */
int ret;
+ unsigned int wait_us;
};
#if defined(CONFIG_REGULATOR)
@@ -192,7 +193,7 @@ int devm_regulator_bulk_register_supply_alias(struct device *dev,
int num_id);
/* regulator output control and status */
-int __must_check regulator_enable(struct regulator *regulator);
+int __must_check regulator_enable_and_wait(struct regulator *regulator, unsigned int ms);
int regulator_disable(struct regulator *regulator);
int regulator_force_disable(struct regulator *regulator);
int regulator_is_enabled(struct regulator *regulator);
@@ -209,8 +210,9 @@ int __must_check devm_regulator_bulk_get_const(
struct device *dev, int num_consumers,
const struct regulator_bulk_data *in_consumers,
struct regulator_bulk_data **out_consumers);
-int __must_check regulator_bulk_enable(int num_consumers,
- struct regulator_bulk_data *consumers);
+int __must_check regulator_bulk_enable_and_wait(int num_consumers,
+ struct regulator_bulk_data *consumers,
+ unsigned int wait_us);
int devm_regulator_bulk_get_enable(struct device *dev, int num_consumers,
const char * const *id);
int regulator_bulk_disable(int num_consumers,
@@ -410,7 +412,8 @@ static inline int devm_regulator_bulk_register_supply_alias(struct device *dev,
return 0;
}
-static inline int regulator_enable(struct regulator *regulator)
+static inline int regulator_enable_and_wait(struct regulator *regulator,
+ unsigned int wait_us)
{
return 0;
}
@@ -457,8 +460,9 @@ static inline int devm_regulator_bulk_get_const(
return 0;
}
-static inline int regulator_bulk_enable(int num_consumers,
- struct regulator_bulk_data *consumers)
+static inline int regulator_bulk_enable_and_wait(int num_consumers,
+ struct regulator_bulk_data *consumers,
+ unsigned int wait_us)
{
return 0;
}
@@ -676,6 +680,11 @@ regulator_is_equal(struct regulator *reg1, struct regulator *reg2)
}
#endif
+#define regulator_enable(regulator) regulator_enable_and_wait(regulator, 0)
+
+#define regulator_bulk_enable(num_consumers, consumers) \
+ regulator_bulk_enable_and_wait(num_consumers, consumers, 0)
+
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_REGULATOR)
struct regulator *__must_check of_regulator_get(struct device *dev,
struct device_node *node,
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index cc6ce709ec86..8a74aa681df3 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -658,6 +658,8 @@ struct regulator_dev {
unsigned int constraints_pending:1;
unsigned int is_switch:1;
+ /* time when this regulator was enabled last time */
+ ktime_t last_on;
/* time when this regulator was disabled last time */
ktime_t last_off;
int cached_err;
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH v3 0/9] arm64: mediatek: Chromebook trackpad supply fixes
From: Chen-Yu Tsai @ 2026-07-21 7:52 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti
Cc: Andy Shevchenko, Chen-Yu Tsai, linux-mediatek, devicetree,
linux-arm-kernel, chrome-platform, linux-input, linux-i2c,
linux-kernel
Hi everyone,
This is v3 of my Chromebook trackpad supply fixes and optimization
series.
Changes since v2:
- Added new regulator "enable and wait" functions that wait until at
least the given amount of time has passed since the regulator was
last enabled.
- Converted patches to use the new functions
- New header inclusion cleanup patch for elan_i2c driver
This series fixes the trackpad descriptions on some MediaTek-based
Chromebooks: either the trackpad's supply was set as always-on to
workaround missing delays in the driver, or the delay and supply
are missing from the trackpad's device node.
v1 was just the first patch [1]. It has since grown to cover multiple
drivers and devices.
Patch 1 adds new "enable and wait" functions for single and bulk
regulator enable.
Patch 2 cleans up header inclusion for elan_i2c driver.
Patch 3 adds the correct enable delay after enabling the supply regulator
for the Elan trackpad to initialize. This uses the new "enable and wait"
regulator enable function.
Patch 4 applies the same logic of skipping the power on delay to the
i2c-hid-of driver.
Patch 5 applies the same logic of skipping the power on delay to the
i2c OF component prober library.
Patch 6 adds a delay between when the device node found is enabled and
when regulator_disable() is called. This gives an asynchronously probing
driver some time to increment the enable count of their regulator
reference, thus keeping the device operational and allowing the driver
to skip the initialization delay.
Patch 7 adds the correct delay for probing trackpads for Hana devices
to the ChromeOS OF component prober.
Patch 8 removes the "always-on" setting from the trackpad supply for
Elm / Hana and adds the correct delay to the second source trackpad.
This corrects the hardware description.
Patch 9 adds the supply and power on delay properties to the Synaptics
trackpad on the Spherion device. Combined with previous driver changes
this should cause no actual functional changes or delays.
Please take a look. Patches 3, 4, and 5 have build time dependencies
on patch 1. I suggest placing patch 1 on a separate immutable branch
or tag for the other maintainers to pull in. The three patches all have
different maintainers.
The DT changes must go in after all the driver changes land, especially
patch 3 that adds delays to the Elan trackpad driver. Otherwise the user
could potentially end up with a non-functional trackpad on the device.
Thanks
ChenYu
[1] https://lore.kernel.org/all/20241001093815.2481899-1-wenst@chromium.org/
Chen-Yu Tsai (9):
regulator: core: Add "enable and wait" functions
Input: elan_i2c - sort include statements
Input: elan_i2c - Wait for initialization after enabling regulator
supply
HID: i2c-hid-of: skip post-power-on delay if powered on sufficiently
long
i2c: of-prober: skip post-power-on delay if powered on sufficiently
long
i2c: of-prober: Defer regulator_disable() on successful probe in
simple helper
platform/chrome: of_hw_prober: Add delay for hana trackpads
arm64: dts: mediatek: mt8173-elm-hana: Unmark trackpad supply as
always-on
arm64: dts: mediatek: mt8192-asurada-spherion: Add Synaptics
trackpad's supply
.../boot/dts/mediatek/mt8173-elm-hana.dtsi | 8 +--
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 -
.../mediatek/mt8192-asurada-spherion-r0.dts | 2 +
drivers/hid/i2c-hid/i2c-hid-of.c | 9 ++--
drivers/i2c/i2c-core-of-prober.c | 25 ++++++---
drivers/input/mouse/elan_i2c_core.c | 23 ++++----
.../platform/chrome/chromeos_of_hw_prober.c | 4 +-
drivers/regulator/core.c | 53 ++++++++++++++-----
include/linux/regulator/consumer.h | 21 +++++---
include/linux/regulator/driver.h | 2 +
10 files changed, 96 insertions(+), 52 deletions(-)
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply
* Re: [PATCH v4 2/4] media: synopsys: hdmirx: add HDMI audio capture support
From: Igor Paunovic @ 2026-07-21 7:51 UTC (permalink / raw)
To: sashiko-reviews, Dmitry Osipenko, Mauro Carvalho Chehab,
Sebastian Reichel, Heiko Stübner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, linux-kernel
Cc: robh, media-ci, conor+dt, devicetree
In-Reply-To: <20260721070036.51C371F000E9@smtp.kernel.org>
> Does this byte reversal using swab32() incorrectly scramble the N and
> CTS values?
No. This is the third review of this finding -- it was raised on v2
and v3 in the be32_to_cpu() spelling and answered both times, and the
comment above the code documents the layout. The premise doesn't
match the ACR subpacket format: CTS is not stored LSB-first from PB1.
Per the HDMI spec, subpacket byte 0 is reserved, CTS[19:16] sits in
PB1[3:0], CTS[15:8] in PB2 and CTS[7:0] in PB3 -- MSB first -- with N
likewise in PB4..PB6. The packet decoder stores PB0 in register bits
[7:0], so reversing the word is precisely what lines the bytes up
before the 20-bit masks. swab32() and the previous
be32_to_cpu()/cpu_to_be32 spelling produce the same value on both
endiannesses; the v4 change only makes the reversal unconditional.
It also remains the path validated on hardware, as noted in the
cover letter: a 44.1 kHz source is detected as 44.1 kHz rather than
falling back to the 48 kHz default, and 44.1/48 kHz switches are
followed. Neither would work if the extraction produced garbage.
> is there a use-after-free risk during device unbind in this driver?
> [video_device embedded in devm-allocated struct, release set to
> video_device_release_empty]
This one looks structurally plausible, but as the report itself
notes it predates this series: it concerns the video_device lifetime
on the V4L2 side and is independent of the audio support added here
(the audio teardown path was exercised on unbind with an active
stream during v3 review, see the v3 thread). Addressing it would be
a separate fix for the existing driver -- happy to leave that call
to Dmitry.
Igor
On Tue, Jul 21, 2026 at 9:00 AM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> New issues:
> - [High] The use of `swab32()` when extracting the 20-bit ACR N and CTS values incorrectly scrambles their bits. Because the packet bytes are stored contiguously from the LSB up (PB0 in [7:0], PB1 in [15:8], etc.), reversing the 32-bit word using `swab32()` places the LSB of CTS (PB1) into the MSB of the extracted value, and the MSB of CTS (PB3) into the LSB. Masking this result produces a completely invalid sample rate.
>
> Pre-existing issues:
> - [High] The V4L2 `video_device` is embedded in `struct snps_hdmirx_dev`, which is allocated using `devm_kzalloc`. The driver sets `vdev.release = video_device_release_empty`. If a user space process keeps the `/dev/videoX` file descriptor open during device unbind, the `devm` subsystem will free the `snps_hdmirx_dev` memory. When the process later closes the file descriptor, the V4L2 core will access the freed `video_device` to decrement its refcount and call the release callback, causing a use-after-free vulnerability.
> --
>
> --- Patch [2]: [PATCH v4 2/4] media: synopsys: hdmirx: add HDMI audio capture support ---
> commit 19c9c4db1394f1dc0fc1cb44d51317198a87b078
> Author: Igor Paunovic <royalnet026@gmail.com>
> Date: Tue Jul 21 06:41:13 2026 +0000
>
> media: synopsys: hdmirx: add HDMI audio capture support
>
> This patch adds HDMI audio capture support to the Synopsys DesignWare HDMI RX
> controller. It extracts the embedded audio stream and exposes it as an ALSA
> capture device via the generic hdmi-codec. It also introduces a periodic
> worker to keep the local audio reference clock locked to the source.
>
> > diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> > index 25f8ca0d6d946..1b4a7fda9e195 100644
> > --- a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> > +++ b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
>
> [ ... ]
>
> > +static u32 hdmirx_audio_fs(struct snps_hdmirx_dev *hdmirx_dev)
> > +{
> > + u64 tmds_clk, fs_audio = 0;
> > + u32 acr_cts, acr_n, tmdsqpclk_freq;
> > + u32 acr_pb3_0, acr_pb7_4;
> > +
> > + tmdsqpclk_freq = hdmirx_readl(hdmirx_dev, CMU_TMDSQPCLK_FREQ);
> > + hdmirx_readl(hdmirx_dev, PKTDEC_ACR_PH2_1);
> > + acr_pb3_0 = hdmirx_readl(hdmirx_dev, PKTDEC_ACR_PB3_0);
> > + acr_pb7_4 = hdmirx_readl(hdmirx_dev, PKTDEC_ACR_PB7_4);
> > + /*
> > + * The packet decoder stores the ACR subpacket bytes with packet byte
> > + * 0 in register bits [7:0], so byte-reverse each word to line the
> > + * bytes up: CTS is packet bytes 1-3 (PKTDEC_ACR_PB3_0) and N is
> > + * packet bytes 4-6 (PKTDEC_ACR_PB7_4), 20 bits each. readl()
> > + * already abstracts the bus endianness, so the reversal is
> > + * unconditional.
> > + */
> > + acr_cts = swab32(acr_pb3_0) & 0xfffff;
> > + acr_n = (swab32(acr_pb7_4) & 0x0fffff00) >> 8;
>
> [Severity: High]
> Does this byte reversal using swab32() incorrectly scramble the N and CTS
> values?
>
> Because the packet bytes are stored contiguously from the LSB up (with packet
> byte 0 in [7:0], packet byte 1 in [15:8], etc.), reversing the 32-bit word
> using swab32() places the LSB of CTS (from PB1) into the MSB of the extracted
> value, and the MSB of CTS (from PB3) into the LSB.
>
> Will this result in an invalid sample rate being calculated, causing the
> driver's fallback logic to silently ignore the broken rate and use 48kHz? This
> could cause any audio stream not natively at 48kHz to be played back at the
> wrong rate.
>
> > + tmds_clk = tmdsqpclk_freq * 4 * 1000U;
> > + if (acr_cts != 0) {
> > + fs_audio = div_u64((tmds_clk * acr_n), acr_cts);
>
> [ ... ]
>
> > @@ -2765,6 +3064,10 @@ static int hdmirx_probe(struct platform_device *pdev)
> > V4L2_DEBUGFS_IF_AVI, hdmirx_dev,
> > hdmirx_debugfs_if_read);
> >
> > + ret = hdmirx_register_audio_device(hdmirx_dev);
> > + if (ret)
> > + dev_warn(dev, "failed to register HDMI audio codec: %d\n", ret);
> > +
> > return 0;
>
> [Severity: High]
> This isn't a bug introduced by this patch, but is there a use-after-free risk
> during device unbind in this driver?
>
> The V4L2 video_device is embedded in struct snps_hdmirx_dev, which is
> allocated using devm_kzalloc() earlier in hdmirx_probe(). However, the driver
> sets the release callback to video_device_release_empty in
> hdmirx_register_stream_vdev().
>
> If a user space process keeps the /dev/videoX file descriptor open during
> device unbind (such as during driver unbind or module removal), the devm
> subsystem will free the snps_hdmirx_dev memory. When the process later closes
> the file descriptor, will the V4L2 core access the freed video_device memory
> to decrement its refcount and call the release callback?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260721064115.64809-1-royalnet026@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH net v5] net: airoha: fix MIB stats collection to be lossless
From: patchwork-bot+netdevbpf @ 2026-07-21 7:50 UTC (permalink / raw)
To: Aniket Negi
Cc: netdev, lorenzo, matthias.bgg, angelogioacchino.delregno,
aniket.negi, andrew+netdev, davem, edumazet, kuba, pabeni, horms,
ansuelsmth, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260707152639.105628-1-aniket.negi03@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 7 Jul 2026 20:56:39 +0530 you wrote:
> REG_FE_GDM_MIB_CLEAR after every read creates a race window where
> packets arriving between read and clear are lost from statistics.
>
> Switch to a delta-based approach instead:
>
> - 64-bit H+L registers (ok pkts/bytes, E64..L1023): read absolute
> hardware total directly into a local variable; clamp with max(new, old)
> to prevent torn-read regression when the counter carries between the
> two reads.
>
> [...]
Here is the summary with links:
- [net,v5] net: airoha: fix MIB stats collection to be lossless
https://git.kernel.org/netdev/net/c/d163725af84a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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