* [PATCH] ARM: select HAVE_POSIX_CPU_TIMERS_TASK_WORK
From: Karl Mehltretter @ 2026-07-18 21:45 UTC (permalink / raw)
To: Russell King, Sebastian Andrzej Siewior
Cc: Karl Mehltretter, Arnd Bergmann, linux-rt-devel, linux-arm-kernel
Commit c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") enabled PREEMPT_RT
on ARM but did not select HAVE_POSIX_CPU_TIMERS_TASK_WORK. This leaves
CONFIG_POSIX_CPU_TIMERS_TASK_WORK disabled, so CPU timers expire in hard
IRQ context.
On PREEMPT_RT this makes run_posix_cpu_timers() take the sleeping
sighand->siglock:
BUG: sleeping function called from invalid context at spinlock_rt.c:48
rt_spin_lock from lock_task_sighand
lock_task_sighand from run_posix_cpu_timers
run_posix_cpu_timers from update_process_times
ARM handles TIF_NOTIFY_RESUME on all return-to-user paths, including v7-M.
ARM32 KVM host support was removed by commit 541ad0150ca4 ("arm: Remove
32bit KVM host support"), so the select need not be conditional on KVM.
Select it to defer POSIX CPU timer expiry to task context.
Reproduced with setrlimit(RLIMIT_CPU, ...) and a busy loop. The same path
is used by setitimer(ITIMER_PROF or ITIMER_VIRTUAL) and POSIX CPU timers
created with timer_create().
Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Found with a self-hosted syzkaller instance patched to fuzz kernels on
QEMU's versatilepb machine (ARM926EJ-S, ARMv5TE). Runtime-tested before
and after the change on that setup, and compile-tested mps2_defconfig
with PREEMPT_RT (NOMMU, CPU_V7M).
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9187240a02db..f073b5102d4e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -133,6 +133,7 @@ config ARM
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_POSIX_CPU_TIMERS_TASK_WORK
select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RSEQ
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next] net: stmmac: Simplify ioctl handling
From: Vadim Fedorenko @ 2026-07-18 21:19 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn, Jakub Kicinski, davem,
Eric Dumazet, Paolo Abeni, Simon Horman, Maxime Coquelin,
Alexandre Torgue, Russell King
Cc: thomas.petazzoni, Alexis Lothoré, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260718143848.677531-1-maxime.chevallier@bootlin.com>
On 18.07.2026 15:38, Maxime Chevallier wrote:
> Now that timestamping is controlled through an NDO, we can simply
> call phylink_mii_ioctl() to handle ioctls.
>
> The only functional difference is that phylink_mii_ioctl() ->
> phy_mii_ioctl() can handle SIOCSHWTSTAMP, but this no longer happens
> as this ioctl is not longer dispatched to the ndo_eth_ioctl().
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>
> Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
> handling in phy_mii_ioctl(). Looks like we can ?
>
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 17 +++--------------
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 2a0d7eff88d3..562d20830b94 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -6371,28 +6371,17 @@ static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
> * @rq: An IOCTL specific structure, that can contain a pointer to
> * a proprietary structure used to pass information to the driver.
> * @cmd: IOCTL command
> - * Description:
> - * Currently it supports the phy_mii_ioctl(...) and HW time stamping.
> + * Description: Forward the PHY ioctls to phylink
> + * Return: Zero on success or negative error code.
> */
> static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> {
> struct stmmac_priv *priv = netdev_priv (dev);
> - int ret = -EOPNOTSUPP;
>
> if (!netif_running(dev))
> return -EINVAL;
>
> - switch (cmd) {
> - case SIOCGMIIPHY:
> - case SIOCGMIIREG:
> - case SIOCSMIIREG:
> - ret = phylink_mii_ioctl(priv->phylink, rq, cmd);
> - break;
> - default:
> - break;
> - }
> -
> - return ret;
> + return phylink_mii_ioctl(priv->phylink, rq, cmd);
> }
>
> static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add Vicharak Vaaman board
From: Andrew Lunn @ 2026-07-18 20:58 UTC (permalink / raw)
To: Hrushiraj Gandhi
Cc: heiko, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
robh, krzk+dt, conor+dt
In-Reply-To: <20260718065900.755631-3-hrushirajg23@gmail.com>
> +&gmac {
> + assigned-clocks = <&cru SCLK_RMII_SRC>;
> + assigned-clock-parents = <&clkin_gmac>;
> + clock_in_out = "input";
> + phy-supply = <&vcc3v3_lan>;
> + /* TX/RX delays tuned for the Vaaman board PCB trace lengths */
> + phy-mode = "rgmii";
Please could you read:
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
and then expand the comment to explain in detail what is going on
here.
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> + snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 10000 50000>;
> + tx_delay = <0x28>;
> + rx_delay = <0x11>;
> + status = "okay";
> +};
I don't see a phy-handle here?
Andrew
^ permalink raw reply
* Re: [PATCH] iommu/io-pgtable-arm: Add support for contiguous hint bit
From: Mostafa Saleh @ 2026-07-18 20:11 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Vijayanand Jitta, Joerg Roedel (AMD), Robin Murphy,
linux-arm-msm, iommu, linux-kernel, linux-arm-kernel,
Prakash Gupta
In-Reply-To: <20260715122830.GB3775915@nvidia.com>
On Wed, Jul 15, 2026 at 09:28:30AM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 15, 2026 at 01:03:22PM +0100, Will Deacon wrote:
>
> > From what I can tell, the fiddly parts for iommupt will be:
> >
> > 1. Hardware bugs / quirks. Some of the simpler ones could probably be
> > handled but for the more invasive stuff like the Mali format
> > format, io-pgtable will probably need to hang around. Perhaps
> > it becomes io-pgtable-mali.c?
>
> I briefly looked at Mali a while back and it didn't seem so bad, but
> that was for a GPU driver not the iommu so a bit different
> issue. Exactly what the GPU drivers should be doing is less clear to
> me, they don't really fit well with the iommu focused interface (eg
> the memory preload issues/etc).
>
> > 2. The pKVM work from Mostafa. We'll probably end up with something
> > separate at EL2 for this (ideally, just reusing the CPU page-table
> > code when it learns about BBML3).
>
> Yeah, I'm not sure here, it isn't great that is adding another user
> and open coding some of the logic (eg smmu_pgsize_idmap). It would be
> much better if it could just use all the existing flow more directly
> somehow.
I was under the impression that io-pgtable-arm will remain the same,
but if it is going to be removed (or at least the LPAE format) I need
to figure out an alternative for pKVM:
- Compile iommupt for the hypervisor (similar to what we do with
io-pgtable-arm in the SMMUv3 pKVM series which compiles in both)
I am not sure how easy is that for iommupt, I have the SMMUv3
iommupt series on my review list, I will check that.
- Support the hypervisor page table in the IOMMU, that requires some
extra support changes, I recently posted BBM support, but there is
more as avoiding lazy mapping when unmapping, TLB hooks...).
There is another problem with that for android, as we still need
stage-1 as some SMMUs only support single stage (used with pv)
- Write a small IO page table implementation just for the hypervisor,
that's not ideal as it would benefit also from features as CONTPTE.
I will look more into this, solution 1) seems the best case if
practical, otherwise, 2) might be reasonable for upstream.
Thanks,
Mostafa
>
> > 3. Non-coherent walkers, although I think this might actually be fine
> > because x86 needs it anyway?
>
> This is done already, the smmuv3 conversion I've posted supports it.
>
> > So, for now, I wouldn't require new drivers to use iommupt but I'm
>
> The recently posted broadcom driver used iommupt and I thought it
> turned out very clean, it actually seems like less work to do it this
> way than try to write your own page table like that rockchip driver
> did which required several review rounds.
>
> Jason
^ permalink raw reply
* Re: [RFC PATCH 2/2] KVM: arm64: Support BBM level 3
From: Mostafa Saleh @ 2026-07-18 19:54 UTC (permalink / raw)
To: Oliver Upton
Cc: linux-kernel, kvmarm, linux-arm-kernel, maz, seiden, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, vdonnefort,
tabba
In-Reply-To: <alqW49CH7eViDpAZ@kernel.org>
Hi Oliver,
On Fri, Jul 17, 2026 at 01:56:03PM -0700, Oliver Upton wrote:
> Hi Mostafa,
>
> On Fri, Jul 17, 2026 at 01:09:00PM +0000, Mostafa Saleh wrote:
> > If the system supports hardware Break-Before-Make (BBM) level 3, use it
> > to replace stage-2 PTEs directly instead of falling back to the software
> > break-before-make sequence.
> >
> > 1) Get a reference count on the containing table for the new PTE.
> > 2) Atomically update the PTE with the new valid descriptor.
> > 3) Invalidate the TLB for the old PTE.
> > 4) Drop the reference count holding the old PTE.
> >
> > One interesting case, as BBML3 will update the PTE atomically, it
> > can only know it raced with another core at the point of the cmpxchg
> > failing, unlike the SW implementation which locks the PTE first.
> > And as we must issue CMOs to the new mapped page before the update,
> > that means with BBML3 racing cores will issue redundant CMOs,
>
> I'd rather we just predicate BBML3-style transformations on an
> implementation having FEAT_S2FWB and DIC. You can definitely come along
> later and enable it when using a stage-2 in an SMMU makes this
> mandatory, possibly at the expense of some extra CMOs.
Makes sense, I will do that in v2.
>
> There's also an extremely subtle detail that BBML3 enablement relies on,
> which is that KVM will never change the OA of active translation. IOW,
> if the host is moving the PFN we expect an invalidation before
> re-mapping it.
>
> I have no issue with relying on that behavior but we should make that
> assumption abundantly clear.
I see, I can add a comment as:
Note: we assume that KVM will never change the OA of an active
translation. If the host needs to move the backing PFN,it should do
an explicit unmap to issue the required TLBI.
>
> One of the things on my wish list for a while has been rebuilding
> hugepages after dirty logging is disabled on a memslot. That seems like
> like a very good optimization to do when BBML3 is present.
>
In android we have support for coalescing for KVM_PGTABLE_S2_IDMAP
on map, that does not rely on BBML3, maybe this can be added in a
follow-up series, and eventually extended to be more generic.
https://android.googlesource.com/kernel/common/+/refs/heads/android17-6.18/arch/arm64/kvm/hyp/pgtable.c#1107
> > to improve this:
> > - We only use BBML3 if the old PTE was live.
> > - To reduce the window of the race, an early check is added before
> > the CMO to exit early, but that does not eliminate the race.
> >
> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > ---
> > arch/arm64/kvm/hyp/pgtable.c | 53 +++++++++++++++++++++++++++++++-----
> > 1 file changed, 46 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 127b7f9541b1..69d52308236f 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > @@ -838,7 +838,8 @@ static void stage2_clean_old_pte(const struct kvm_pgtable_visit_ctx *ctx,
> > /**
> > * stage2_try_break_pte() - Invalidates a pte according to the
> > * 'break-before-make' requirements of the
> > - * architecture.
> > + * architecture, if BMML3 is supported it
> > + * will be used, otherwise fallback to SW.
> > *
> > * @ctx: context of the visited pte.
> > * @mmu: stage-2 mmu
> > @@ -854,6 +855,18 @@ static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
> > {
> > kvm_pte_t locked_pte;
> >
> > + if (system_supports_bbml3() && kvm_pte_valid(ctx->old)) {
> > + kvm_pte_t curr_pte = READ_ONCE(*ctx->ptep);
> > +
> > + /*
> > + * All handled in stage2_make_pte(). However exit early if we already
> > + * lost the race to avoid extra CMOs.
> > + */
> > + if (curr_pte != ctx->old)
> > + return false;
>
> Does this race detection actually move the needle? We haven't gotten
> very far from the read in __kvm_pgtable_visit().
Yes, doesn't seem to help much with the current users, I will drop it.
Thanks,
Mostafa
>
> Thanks,
> Oliver
^ permalink raw reply
* [PATCH] arm64: entry: dedup SDEI event priority selection
From: Bradley Morgan @ 2026-07-18 18:54 UTC (permalink / raw)
To: catalin.marinas, will, linux-arm-kernel
Cc: kees, Bradley Morgan, linux-kernel, anshuman.khandual
__sdei_asm_handler open codes the same branch ladder four times to pick
the normal or critical variant of a per CPU variable based on the SDEI
event priority: when recording the active event, when selecting the
SDEI stack, when selecting the shadow call stack, and when clearing the
active-event record on exit.
Add a sdei_choose macro, using \@ local labels like the files existing
macros, and replace the four open coded copies with it. This also drops
the repeated reuse of the 1:/2:/3:/4: numeric labels in this handler.
No functional change intended.
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
arch/arm64/kernel/entry.S | 39 +++++++++++++++++++--------------------
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index e0db14e9c843..29ef4a0d28a8 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -916,6 +916,15 @@ NOKPROBE(call_on_irq_stack)
b .
.endm
+/* Set \dst using \op and the \normal or \critical sym, based on \prio */
+.macro sdei_choose op:req, dst:req, prio:req, normal:req, critical:req, tmp:req
+ cbnz \prio, .Lcritical\@
+ \op dst=\dst, sym=\normal, tmp=\tmp
+ b .Ldone\@
+.Lcritical\@: \op dst=\dst, sym=\critical, tmp=\tmp
+.Ldone\@:
+.endm
+
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
/*
* The regular SDEI entry point may have been unmapped along with the rest of
@@ -997,32 +1006,24 @@ SYM_CODE_START(__sdei_asm_handler)
/* Store the registered-event for crash_smp_send_stop() */
ldrb w4, [x19, #SDEI_EVENT_PRIORITY]
- cbnz w4, 1f
- adr_this_cpu dst=x5, sym=sdei_active_normal_event, tmp=x6
- b 2f
-1: adr_this_cpu dst=x5, sym=sdei_active_critical_event, tmp=x6
-2: str x19, [x5]
+ sdei_choose adr_this_cpu, x5, w4, sdei_active_normal_event, \
+ sdei_active_critical_event, x6
+ str x19, [x5]
/*
* entry.S may have been using sp as a scratch register, find whether
* this is a normal or critical event and switch to the appropriate
* stack for this CPU.
*/
- cbnz w4, 1f
- ldr_this_cpu dst=x5, sym=sdei_stack_normal_ptr, tmp=x6
- b 2f
-1: ldr_this_cpu dst=x5, sym=sdei_stack_critical_ptr, tmp=x6
-2: mov x6, #SDEI_STACK_SIZE
+ sdei_choose ldr_this_cpu, x5, w4, sdei_stack_normal_ptr, sdei_stack_critical_ptr, x6
+ mov x6, #SDEI_STACK_SIZE
add x5, x5, x6
mov sp, x5
#ifdef CONFIG_SHADOW_CALL_STACK
/* Use a separate shadow call stack for normal and critical events */
- cbnz w4, 3f
- ldr_this_cpu dst=scs_sp, sym=sdei_shadow_call_stack_normal_ptr, tmp=x6
- b 4f
-3: ldr_this_cpu dst=scs_sp, sym=sdei_shadow_call_stack_critical_ptr, tmp=x6
-4:
+ sdei_choose ldr_this_cpu, scs_sp, w4, sdei_shadow_call_stack_normal_ptr, \
+ sdei_shadow_call_stack_critical_ptr, x6
#endif
/*
@@ -1068,11 +1069,9 @@ SYM_CODE_START(__sdei_asm_handler)
/* Clear the registered-event seen by crash_smp_send_stop() */
ldrb w3, [x4, #SDEI_EVENT_PRIORITY]
- cbnz w3, 1f
- adr_this_cpu dst=x5, sym=sdei_active_normal_event, tmp=x6
- b 2f
-1: adr_this_cpu dst=x5, sym=sdei_active_critical_event, tmp=x6
-2: str xzr, [x5]
+ sdei_choose adr_this_cpu, x5, w3, sdei_active_normal_event, \
+ sdei_active_critical_event, x6
+ str xzr, [x5]
alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0
sdei_handler_exit exit_mode=x2
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] ASoC: topology: Guard against out-of-range mixer control shift
From: Mark Brown @ 2026-07-18 18:53 UTC (permalink / raw)
To: Daniel Golle
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Matthias Brugger,
AngeloGioacchino Del Regno, linux-sound, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <fb5d83513eda68578f0275b7fa274f172c08a0b1.1784395999.git.daniel@makrotopia.org>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
On Sat, Jul 18, 2026 at 06:34:42PM +0100, Daniel Golle wrote:
> soc_tplg_control_dmixer_create() copies the per-channel "shift" field from
> the topology file verbatim into struct soc_mixer_control. That value is
> later used as a shift amount in soc_get_volsw() / soc_put_volsw() (e.g.
> sm->shift = tplg_chan_get_shift(tplg, mc->channel, SNDRV_CHMAP_FL);
> sm->rshift = tplg_chan_get_shift(tplg, mc->channel, SNDRV_CHMAP_FR);
>
> + if (sm->shift >= 32 || sm->rshift >= 32) {
Won't this break for mono controls - the right shift lookup will return
a negative error code?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] ARM: Drop outdated links in comments
From: Lincoln Wallace @ 2026-07-18 17:51 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux, kees, will, linusw, f.fainelli, catalin.marinas, joe,
linux-kernel, Kees Cook, Lincoln Wallace
From: Kees Cook <keescook@chromium.org>
As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org links
with lore"), an effort was made to replace lkml.org links with lore to
better use a single source that's more likely to stay available long-term.
However, it seems these links don't offer much value here, so just
remove them entirely.
This is the arch/arm counterpart to commit 89d30b11507d ("arm64: Drop
outdated links in comments"). The arch/arm hunk was dropped from that
commit at the maintainer's request [1] and asked to be submitted
separately via the ARM patch system.
Cc: Joe Perches <joe@perches.com>
Suggested-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/lkml/20210211100213.GA29813@willie-the-truck/
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20211215191835.1420010-1-keescook@chromium.org [1]
Signed-off-by: Lincoln Wallace <locnnil0@gmail.com>
---
This resurrects Kees Cook's arch/arm hunk, split off from 89d30b11507d at
the maintainer's request; authorship and changelog are preserved, with my
SoB added as the one submitting it.
Note: checkpatch's PREFER_LORE_ARCHIVE warning fires on the removed
lkml.org line (the check matches $rawline with no added-line guard, so it
flags deletions too). Nothing to convert, the link is being removed.
arch/arm/kernel/hibernate.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/kernel/hibernate.c b/arch/arm/kernel/hibernate.c
index 231a76af09a0..5bec408478d2 100644
--- a/arch/arm/kernel/hibernate.c
+++ b/arch/arm/kernel/hibernate.c
@@ -7,10 +7,6 @@
* Ubuntu project, hibernation support for mach-dove
* Copyright (C) 2010 Nokia Corporation (Hiroshi Doyu)
* Copyright (C) 2010 Texas Instruments, Inc. (Teerth Reddy et al.)
- * https://lkml.org/lkml/2010/6/18/4
- * https://lists.linux-foundation.org/pipermail/linux-pm/2010-June/027422.html
- * https://patchwork.kernel.org/patch/96442/
- *
* Copyright (C) 2006 Rafael J. Wysocki <rjw@sisk.pl>
*/
--
2.53.0
^ permalink raw reply related
* [PATCH] ASoC: topology: Guard against out-of-range mixer control shift
From: Daniel Golle @ 2026-07-18 17:34 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek
soc_tplg_control_dmixer_create() copies the per-channel "shift" field from
the topology file verbatim into struct soc_mixer_control. That value is
later used as a shift amount in soc_get_volsw() / soc_put_volsw() (e.g.
"reg_val >> shift" and "mask << shift"). Topology data is loaded from an
untrusted firmware file, and a shift >= 32 (the width of the register
value) is undefined behaviour when applied.
This is not hypothetical: mediatek/sof-tplg/sof-mt8186.tplg from
linux-firmware contains a control whose channel shift is 0x01000000, so
every read of that control (e.g. from alsamixer) emits:
UBSAN: shift-out-of-bounds in sound/soc/soc-ops.c:117:21
shift exponent 16777216 is too large for 32-bit type 'unsigned int'
tplg_chan_get_shift() can also return -EINVAL when no matching channel is
found, which becomes a large value once stored in the unsigned shift
field; the same guard covers that case.
Clamp an out-of-range shift to 0 and warn, so the rest of the card stays
usable instead of failing the whole topology load.
Fixes: 8a9782346dcc ("ASoC: topology: Add topology core")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
sound/soc/soc-topology.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c
index 35cbe29d2275..dd94eb9460d3 100644
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -672,6 +672,16 @@ static int soc_tplg_control_dmixer_create(struct soc_tplg *tplg, struct snd_kcon
sm->shift = tplg_chan_get_shift(tplg, mc->channel, SNDRV_CHMAP_FL);
sm->rshift = tplg_chan_get_shift(tplg, mc->channel, SNDRV_CHMAP_FR);
+ if (sm->shift >= 32 || sm->rshift >= 32) {
+ dev_warn(tplg->dev,
+ "ASoC: out-of-range shift for control %s, clamping to 0\n",
+ mc->hdr.name);
+ if (sm->shift >= 32)
+ sm->shift = 0;
+ if (sm->rshift >= 32)
+ sm->rshift = 0;
+ }
+
sm->max = le32_to_cpu(mc->max);
sm->min = le32_to_cpu(mc->min);
sm->invert = le32_to_cpu(mc->invert);
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
--
2.55.0
^ permalink raw reply related
* [PATCH] arm64, mailmap: update email address for Peter Collingbourne
From: Peter Collingbourne @ 2026-07-18 17:29 UTC (permalink / raw)
To: Will Deacon, Nick Desaulniers, Ian Rogers
Cc: Catalin Marinas, Andrew Morton, Jakub Kicinski,
Alexander Sverdlin, Martin Kepplinger-Novaković, Chuck Lever,
Stéphane Grosjean, Eugen Hristev, Peter Collingbourne,
linux-kernel, linux-arm-kernel
I am no longer at Google.
Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
---
.mailmap | 1 +
arch/arm64/kernel/pi/relocate.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index 735470e21075..47127d6da636 100644
--- a/.mailmap
+++ b/.mailmap
@@ -691,6 +691,7 @@ Paulo Alcantara <pc@manguebit.org> <palcantara@suse.com>
Paulo Alcantara <pc@manguebit.org> <pc@manguebit.com>
Pavankumar Kondeti <quic_pkondeti@quicinc.com> <pkondeti@codeaurora.org>
Peter A Jonsson <pj@ludd.ltu.se>
+Peter Collingbourne <peter@pcc.me.uk> <pcc@google.com>
Peter Hilber <peter.hilber@oss.qualcomm.com> <quic_philber@quicinc.com>
Peter Oruba <peter.oruba@amd.com>
Peter Oruba <peter@oruba.de>
diff --git a/arch/arm64/kernel/pi/relocate.c b/arch/arm64/kernel/pi/relocate.c
index 2407d2696398..82592f3a5c1c 100644
--- a/arch/arm64/kernel/pi/relocate.c
+++ b/arch/arm64/kernel/pi/relocate.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
// Copyright 2023 Google LLC
// Authors: Ard Biesheuvel <ardb@google.com>
-// Peter Collingbourne <pcc@google.com>
+// Peter Collingbourne <peter@pcc.me.uk>
#include <linux/elf.h>
#include <linux/init.h>
--
2.54.0
^ permalink raw reply related
* [PATCH RESEND] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-18 17:25 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Marcel Holtmann, Luiz Augusto von Dentz
Cc: Neal Gompa, asahi, linux-arm-kernel, linux-bluetooth,
linux-kernel
Initializing a struct using list initializers is hard to read, compared
to that using named initializers is more ideomatic. Convert the macro
used to assign values in the driver's pci_device_id array accordingly.
This change doesn't introduce any changes to the compiled array on an
x86 and an arm64 build.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
it seems in the bluetooth patchwork patches are archived automatically
after a month. And that even if there is recent activity. I consider
that very annoying for contributors.
So to get back on the list of considered patches, here comes a resend.
The original submission can be found at
https://lore.kernel.org/linux-bluetooth/20260504160940.2168650-2-u.kleine-koenig@baylibre.com
or
https://patchwork.kernel.org/project/bluetooth/patch/20260504160940.2168650-2-u.kleine-koenig@baylibre.com/
.
Best regards
Uwe
drivers/bluetooth/hci_bcm4377.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 925d0a635945..89c317561bfb 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2525,11 +2525,12 @@ static const struct bcm4377_hw bcm4377_hw_variants[] = {
},
};
-#define BCM4377_DEVID_ENTRY(id) \
- { \
- PCI_VENDOR_ID_BROADCOM, BCM##id##_DEVICE_ID, PCI_ANY_ID, \
- PCI_ANY_ID, PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, \
- BCM##id \
+#define BCM4377_DEVID_ENTRY(id) \
+ { \
+ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BCM ## id ## _DEVICE_ID), \
+ .class = PCI_CLASS_NETWORK_OTHER << 8, \
+ .class_mask = 0xffff00, \
+ .driver_data = BCM ## id, \
}
static const struct pci_device_id bcm4377_devid_table[] = {
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* Re: [PATCH] memory: brcmstb_dpfe: validate firmware section sizes
From: Krzysztof Kozlowski @ 2026-07-18 17:14 UTC (permalink / raw)
To: Pengpeng Hou, Markus Mayer
Cc: Broadcom internal kernel review list, Florian Fainelli,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260706092223.78541-1-pengpeng@iscas.ac.cn>
On 06/07/2026 11:22, Pengpeng Hou wrote:
> __verify_firmware() reads a firmware header and sums declared
> data and instruction section sizes with a trailing checksum.
>
> Require the image to contain the header and checksum, and check each
> declared section against the remaining firmware size before computing the
> final total.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/memory/brcmstb_dpfe.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index 08d9e05b1b33..6846e3dac3d3 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -522,6 +522,9 @@ static int __verify_firmware(struct init_data *init,
> bool is_big_endian = false;
> const u32 *chksum_ptr;
>
> + if (fw->size < sizeof(*header) + sizeof(*chksum_ptr))
> + return ERR_INVALID_SIZE;
This looks redundant, there is a check at line 546 for this, no?
> +
> if (header->magic == DPFE_BE_MAGIC)
> is_big_endian = true;
> else if (header->magic != DPFE_LE_MAGIC)
> @@ -539,6 +542,13 @@ static int __verify_firmware(struct init_data *init,
> if ((dmem_size % sizeof(u32)) != 0 || (imem_size % sizeof(u32)) != 0)
> return ERR_INVALID_SIZE;
>
> + if (dmem_size > fw->size - sizeof(*header) - sizeof(*chksum_ptr))
> + return ERR_INVALID_SIZE;
> +
> + if (imem_size > fw->size - sizeof(*header) - sizeof(*chksum_ptr) -
> + dmem_size)
> + return ERR_INVALID_SIZE;
Is this vibe coded with some tools? Look like but I see not Assisted-by
tags.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] drm/bridge: it6505: DP audio support + shared-DAI hw_params fix
From: Daniel Golle @ 2026-07-18 17:02 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, Hermes Wu,
Allen Chen, dri-devel, linux-kernel, linux-arm-kernel,
linux-mediatek
This revives Jiaxin Yu's stalled "drm/bridge: it6505: Add audio support"
v3 [1], rebased onto current mainline, plus the fix needed to make it work
on boards where the it6505 DP output shares an I2S DAI with another codec.
Patch 1 wires up the previously-unused it6505 audio helpers via
hdmi_codec_ops, which unblocks the mt8186-mt6366 sound card that
references it6505 as the I2S3 codec.
Patch 2 stops it6505_audio_setup_hw_params() from returning -ENODEV when
no DP display is attached, which would otherwise tear down the shared
backend and break playback on the co-located codec (the speaker).
Tested on a MediaTek MT8186 (google,steelix) Chromebook: speaker and
built-in mic work. Actual HDMI/DP audio output could not be tested as the
sample exposes no usable DP-audio port.
[1] https://lore.kernel.org/all/20230730180803.22570-4-jiaxin.yu@mediatek.com/
Daniel Golle (1):
drm/bridge: it6505: Don't reject audio hw_params without an encoder
Jiaxin Yu (1):
drm/bridge: it6505: Add audio support
drivers/gpu/drm/bridge/ite-it6505.c | 94 +++++++++++++++++++++++------
1 file changed, 77 insertions(+), 17 deletions(-)
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
prerequisite-patch-id: 0000000000000000000000000000000000000000
--
2.55.0
^ permalink raw reply
* [PATCH 1/2] drm/bridge: it6505: Add audio support
From: Daniel Golle @ 2026-07-18 17:02 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, Hermes Wu,
Allen Chen, dri-devel, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <cover.1784393979.git.daniel@makrotopia.org>
From: Jiaxin Yu <jiaxin.yu@mediatek.com>
Add audio support for it6505 by bridging to the hdmi-codec, registering
an "hdmi-audio-codec" platform device from probe. The it6505's audio
setup/shutdown helpers were merged earlier as unused code; wire them up
via hdmi_codec_ops so the DAI actually appears, which unblocks the
mt8186-mt6366 sound card that references it6505 as the I2S3 codec.
Some DP-to-HDMI dongles get into a bad state if InfoFrame is sent
without audio data, so it6505's audio is only enabled once the stream
is unmuted.
[djg: respin of Jiaxin Yu's v3; rebased onto current tree; the driver
gained it6505->dev so drop the &client->dev usages; hdmi_codec_ops no
longer has .trigger, so enable/disable via .mute_stream instead; drop
now-redundant __maybe_unused on the wired-up helpers]
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
Link: https://lore.kernel.org/all/20230730180803.22570-4-jiaxin.yu@mediatek.com/
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/gpu/drm/bridge/ite-it6505.c | 92 ++++++++++++++++++++++++-----
1 file changed, 76 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index 8ecb43611dba..698ae01b3a47 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2320,19 +2320,12 @@ static void it6505_stop_link_train(struct it6505 *it6505)
static void it6505_link_train_ok(struct it6505 *it6505)
{
- struct device *dev = it6505->dev;
-
it6505->link_state = LINK_OK;
/* disalbe mute enable avi info frame */
it6505_set_bits(it6505, REG_DATA_MUTE_CTRL, EN_VID_MUTE, 0x00);
it6505_set_bits(it6505, REG_INFOFRAME_CTRL,
EN_VID_CTRL_PKT, EN_VID_CTRL_PKT);
- if (it6505_audio_input(it6505)) {
- DRM_DEV_DEBUG_DRIVER(dev, "Enable audio!");
- it6505_enable_audio(it6505);
- }
-
if (it6505->hdcp_desired)
it6505_start_hdcp(it6505);
}
@@ -2960,7 +2953,7 @@ static void it6505_remove_notifier_module(struct it6505 *it6505)
}
}
-static void __maybe_unused it6505_delayed_audio(struct work_struct *work)
+static void it6505_delayed_audio(struct work_struct *work)
{
struct it6505 *it6505 = container_of(work, struct it6505,
delayed_audio.work);
@@ -2974,9 +2967,9 @@ static void __maybe_unused it6505_delayed_audio(struct work_struct *work)
it6505_enable_audio(it6505);
}
-static int __maybe_unused it6505_audio_setup_hw_params(struct it6505 *it6505,
- struct hdmi_codec_params
- *params)
+static int it6505_audio_setup_hw_params(struct it6505 *it6505,
+ struct hdmi_codec_params
+ *params)
{
struct device *dev = it6505->dev;
int i = 0;
@@ -3031,7 +3024,7 @@ static int __maybe_unused it6505_audio_setup_hw_params(struct it6505 *it6505,
return 0;
}
-static void __maybe_unused it6505_audio_shutdown(struct device *dev, void *data)
+static void it6505_audio_shutdown(struct device *dev, void *data)
{
struct it6505 *it6505 = dev_get_drvdata(dev);
@@ -3039,10 +3032,40 @@ static void __maybe_unused it6505_audio_shutdown(struct device *dev, void *data)
it6505_disable_audio(it6505);
}
-static int __maybe_unused it6505_audio_hook_plugged_cb(struct device *dev,
- void *data,
- hdmi_codec_plugged_cb fn,
- struct device *codec_dev)
+static int it6505_audio_hw_params(struct device *dev, void *data,
+ struct hdmi_codec_daifmt *daifmt,
+ struct hdmi_codec_params *params)
+{
+ struct it6505 *it6505 = dev_get_drvdata(dev);
+
+ return it6505_audio_setup_hw_params(it6505, params);
+}
+
+static int it6505_audio_mute(struct device *dev, void *data,
+ bool enable, int direction)
+{
+ struct it6505 *it6505 = dev_get_drvdata(dev);
+
+ DRM_DEV_DEBUG_DRIVER(dev, "mute: %d", enable);
+
+ /*
+ * Some DP-to-HDMI dongles get into a bad state if the InfoFrame is
+ * sent without audio data, so only enable it6505's audio once the
+ * stream is unmuted (i.e. actually playing).
+ */
+ if (enable)
+ cancel_delayed_work(&it6505->delayed_audio);
+ else
+ queue_delayed_work(system_wq, &it6505->delayed_audio,
+ msecs_to_jiffies(180));
+
+ return 0;
+}
+
+static int it6505_audio_hook_plugged_cb(struct device *dev,
+ void *data,
+ hdmi_codec_plugged_cb fn,
+ struct device *codec_dev)
{
struct it6505 *it6505 = data;
@@ -3053,6 +3076,37 @@ static int __maybe_unused it6505_audio_hook_plugged_cb(struct device *dev,
return 0;
}
+static const struct hdmi_codec_ops it6505_audio_codec_ops = {
+ .hw_params = it6505_audio_hw_params,
+ .mute_stream = it6505_audio_mute,
+ .audio_shutdown = it6505_audio_shutdown,
+ .hook_plugged_cb = it6505_audio_hook_plugged_cb,
+};
+
+static int it6505_register_audio_driver(struct device *dev)
+{
+ struct it6505 *it6505 = dev_get_drvdata(dev);
+ struct hdmi_codec_pdata codec_data = {
+ .ops = &it6505_audio_codec_ops,
+ .max_i2s_channels = 8,
+ .i2s = 1,
+ .no_capture_mute = 1,
+ .data = it6505,
+ };
+ struct platform_device *pdev;
+
+ pdev = platform_device_register_data(dev, HDMI_CODEC_DRV_NAME,
+ PLATFORM_DEVID_AUTO, &codec_data,
+ sizeof(codec_data));
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ INIT_DELAYED_WORK(&it6505->delayed_audio, it6505_delayed_audio);
+ DRM_DEV_DEBUG_DRIVER(dev, "bound to %s", HDMI_CODEC_DRV_NAME);
+
+ return 0;
+}
+
static inline struct it6505 *bridge_to_it6505(struct drm_bridge *bridge)
{
return container_of(bridge, struct it6505, bridge);
@@ -3612,6 +3666,12 @@ static int it6505_i2c_probe(struct i2c_client *client)
return err;
}
+ err = it6505_register_audio_driver(dev);
+ if (err < 0) {
+ dev_err(dev, "Failed to register audio driver: %d", err);
+ return err;
+ }
+
INIT_WORK(&it6505->link_works, it6505_link_training_work);
INIT_WORK(&it6505->hdcp_wait_ksv_list, it6505_hdcp_wait_ksv_list);
INIT_DELAYED_WORK(&it6505->hdcp_work, it6505_hdcp_work);
--
2.55.0
^ permalink raw reply related
* [PATCH 2/2] drm/bridge: it6505: Don't reject audio hw_params without an encoder
From: Daniel Golle @ 2026-07-18 17:02 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, Hermes Wu,
Allen Chen, dri-devel, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <cover.1784393979.git.daniel@makrotopia.org>
it6505_audio_setup_hw_params() returns -ENODEV when the bridge is not
attached to a DRM encoder. Now that it6505 registers an hdmi-audio-codec,
this callback runs whenever a stream is configured on the I2S DAI it is
wired to, including when that DAI is shared with another codec. On
mt8186-corsola the speaker amplifier (rt1019) and it6505 share I2S3, so
when the it6505 DP output has no display attached (bridge.encoder is
NULL) the -ENODEV propagates up through dpcm_be_dai_hw_params() and tears
down the whole backend, breaking speaker playback.
A codec must not fail hw_params on a shared DAI just because its own sink
is absent; the actual output is already gated by it6505->powered. Return
0 so the shared link can be configured.
Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index 698ae01b3a47..e88960c82a23 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2979,7 +2979,7 @@ static int it6505_audio_setup_hw_params(struct it6505 *it6505,
params->cea.channels);
if (!it6505->bridge.encoder)
- return -ENODEV;
+ return 0;
if (params->cea.channels <= 1 || params->cea.channels > 8) {
DRM_DEV_DEBUG_DRIVER(dev, "channel number: %d not support",
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v2 5/8] drm/gm12u320: replace struct drm_simple_display_pipe with regular atomic helpers
From: Ze Huang @ 2026-07-18 15:42 UTC (permalink / raw)
To: Thomas Zimmermann, Ze Huang, Alexey Brodkin, Maarten Lankhorst,
Maxime Ripard, David Airlie, Simona Vetter, Joel Stanley,
Andrew Jeffery, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Linus Walleij, Hans de Goede, Alex Lanzano,
Oleksandr Andrushchenko
Cc: dri-devel, linux-kernel, linux-aspeed, linux-arm-kernel, imx,
xen-devel
In-Reply-To: <26981ae1-4aef-4965-8600-f5e30a1b564a@suse.de>
On Fri Jul 17, 2026 at 3:18 PM CST, Thomas Zimmermann wrote:
> Hi
>
> Am 16.07.26 um 11:01 schrieb Ze Huang:
>> Convert gm12u320 to direct primary plane, CRTC and encoder setup.
>>
>> Keep shadow-plane helper state, framebuffer access helpers and
>> no-scaling plane-state check from simple-KMS path.
>>
>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Signed-off-by: Ze Huang <ze.huang@oss.qualcomm.com>
>> ---
>> drivers/gpu/drm/tiny/gm12u320.c | 132 ++++++++++++++++++++++++++++++++--------
>> 1 file changed, 107 insertions(+), 25 deletions(-)
>>
> [...]
>>
>> -static void gm12u320_pipe_enable(struct drm_simple_display_pipe *pipe,
>> - struct drm_crtc_state *crtc_state,
>> - struct drm_plane_state *plane_state)
>> +static void gm12u320_crtc_helper_atomic_enable(struct drm_crtc *crtc,
>> + struct drm_atomic_commit *commit)
>> {
>> struct drm_rect rect = { 0, 0, GM12U320_USER_WIDTH, GM12U320_HEIGHT };
>> - struct gm12u320_device *gm12u320 = to_gm12u320(pipe->crtc.dev);
>> + struct gm12u320_device *gm12u320 = to_gm12u320(crtc->dev);
>> + struct drm_plane_state *plane_state = gm12u320->plane.state;
>
> Did you see the reply from the Sashiko bot?
>
> What happens is that user space can apply multiple atomic commits in a
> row, but they are applied to hardware asynchronously. So if you take the
> plane state here directly from the plane, it could have been replaced by
> a later atomic commit already. Rather get the correct plane state with
> the helper drm_atomic_get_new_plane_state().
>
I think I misunderstood this point. I had assumed that
drm_atomic_get_*_state() was only needed for the state object directly
matching the helper callback, for example crtc_state in
*_crtc_helper_atomic_enable() and plane_state in
*_plane_helper_atomic_update(), while other state could be accessed via
the device-private structure.
From your explanation, I see that this is wrong. In the atomic commit
path, any state associated with the current commit should be obtained
through drm_atomic_get_*_state(), because the object’s ->state may
already refer to a later commit.
> I did not look at all of the series' patches for this problem, but the rule
> applies to all of the mode-setting code.
>
> Best regards
> Thomas
This affects other patches in the series as well, and some drivers may
need additional fixes in internal helpers too, e.g. arc_pgu_set_pxl_fmt()
in arcpgu.c [1].
I will audit the full series and fix such cases in the next version.
Best regards
Ze
^ permalink raw reply
* [PATCH] net: stmmac: dwmac4: mask interrupts before stopping DMA in suspend
From: Luis Lang @ 2026-07-18 15:27 UTC (permalink / raw)
To: netdev
Cc: Luis Lang, Andrew Lunn, Maxime Chevallier, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Ovidiu Panait, Oleksij Rempel, Rohan G Thomas,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
In-Reply-To: <7941d239-e5f5-43b5-ae0f-20398221e027@mail.de>
Since commit 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU
interrupts"), suspending causes an interrupt storm from the RPS
interrupt.
Fix this by adding a deinit_chan() op to stmmac_dma_ops, which
masks all default dma channel interrupts. This is called from
stmmac_stop_all_dma(), so interrupts don't trigger while suspending.
Fixes: 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Luis Lang <luis.la@mail.de>
---
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 24 +++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/hwif.h | 4 ++++
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
3 files changed, 32 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 829a23bdad01..23ffe1adcd0d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -106,6 +106,17 @@ static void dwmac4_dma_init_channel(struct stmmac_priv *priv,
ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
}
+static void dwmac4_dma_deinit_channel(struct stmmac_priv *priv,
+ void __iomem *ioaddr, u32 chan)
+{
+ const struct dwmac4_addrs *dwmac4_addrs = priv->plat->dwmac4_addrs;
+ u32 value;
+
+ value = readl(ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+ value &= ~DMA_CHAN_INTR_DEFAULT_MASK;
+ writel(value, ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+}
+
static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg, u32 chan)
@@ -125,6 +136,17 @@ static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
}
+static void dwmac410_dma_deinit_channel(struct stmmac_priv *priv,
+ void __iomem *ioaddr, u32 chan)
+{
+ const struct dwmac4_addrs *dwmac4_addrs = priv->plat->dwmac4_addrs;
+ u32 value;
+
+ value = readl(ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+ value &= ~DMA_CHAN_INTR_DEFAULT_MASK_4_10;
+ writel(value, ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+}
+
static void dwmac4_dma_init(void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg)
{
@@ -548,6 +570,7 @@ const struct stmmac_dma_ops dwmac4_dma_ops = {
.reset = dwmac4_dma_reset,
.init = dwmac4_dma_init,
.init_chan = dwmac4_dma_init_channel,
+ .deinit_chan = dwmac4_dma_deinit_channel,
.init_rx_chan = dwmac4_dma_init_rx_chan,
.init_tx_chan = dwmac4_dma_init_tx_chan,
.axi = dwmac4_dma_axi,
@@ -577,6 +600,7 @@ const struct stmmac_dma_ops dwmac410_dma_ops = {
.reset = dwmac4_dma_reset,
.init = dwmac4_dma_init,
.init_chan = dwmac410_dma_init_channel,
+ .deinit_chan = dwmac410_dma_deinit_channel,
.init_rx_chan = dwmac4_dma_init_rx_chan,
.init_tx_chan = dwmac4_dma_init_tx_chan,
.axi = dwmac4_dma_axi,
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index e6317b94fff7..04dafec021b4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -170,6 +170,8 @@ struct stmmac_dma_ops {
void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg);
void (*init_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg, u32 chan);
+ void (*deinit_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
+ u32 chan);
void (*init_rx_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg,
dma_addr_t phy, u32 chan);
@@ -235,6 +237,8 @@ struct stmmac_dma_ops {
stmmac_do_void_callback(__priv, dma, init, __args)
#define stmmac_init_chan(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, init_chan, __priv, __args)
+#define stmmac_deinit_chan(__priv, __args...) \
+ stmmac_do_void_callback(__priv, dma, deinit_chan, __priv, __args)
#define stmmac_init_rx_chan(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, init_rx_chan, __priv, __args)
#define stmmac_init_tx_chan(__priv, __args...) \
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..af29a50ddb89 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2560,6 +2560,7 @@ static void stmmac_stop_all_dma(struct stmmac_priv *priv)
{
u8 rx_channels_count = priv->plat->rx_queues_to_use;
u8 tx_channels_count = priv->plat->tx_queues_to_use;
+ u8 dma_csr_ch = max(rx_channels_count, tx_channels_count);
u8 chan;
for (chan = 0; chan < rx_channels_count; chan++)
@@ -2567,6 +2568,9 @@ static void stmmac_stop_all_dma(struct stmmac_priv *priv)
for (chan = 0; chan < tx_channels_count; chan++)
stmmac_stop_tx_dma(priv, chan);
+
+ for (chan = 0; chan < dma_csr_ch; chan++)
+ stmmac_deinit_chan(priv, priv->ioaddr, chan);
}
/**
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v2] media: mtk-jpeg: drain hardware completion before freeing context
From: Nicolas Dufresne @ 2026-07-18 14:56 UTC (permalink / raw)
To: Guangshuo Li, Bin Liu, Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, Hans Verkuil, Fan Wu, linux-media,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260718112448.3289122-1-lgs201920130244@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12066 bytes --]
Le samedi 18 juillet 2026 à 19:24 +0800, Guangshuo Li a écrit :
> The change referenced by the Fixes tag cancels ctx->jpeg_work before
> freeing the JPEG context.
>
> That prevents the worker itself from accessing the context after it has
> been freed. However, the multi-core workers return after programming a
> hardware instance. The IRQ handler or the per-hardware timeout work can
> then continue to access the context through hw_param.curr_ctx after the
> worker has completed.
>
> If userspace closes the file while a hardware job is still pending,
> cancel_work_sync() can return and mtk_jpeg_release() can free the
> context before the IRQ or timeout path has finished using it.
>
> Track the number of in-flight hardware jobs for each context and wait
> for them to complete in mtk_jpeg_release().
>
> Use a per-hardware active flag to ensure that only the IRQ handler or
> the timeout work completes each job. Clear hw_param.curr_ctx and drop
> the in-flight count only after the completion path has finished all
> accesses to the context.
>
> Fixes: 34c519feef3e ("media: mtk-jpeg: fix use-after-free in release path due to uncancelled work")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> v2:
> - Replace the undefined mtk_jpeg_release_hw() call with per-context
> in-flight hardware job tracking.
> - Ensure that only the IRQ or timeout path completes each hardware job.
> - Clear hw_param.curr_ctx after the completion path stops using the
> context.
> - Keep hardware instances busy until the timeout path has finished
> accessing their saved context and buffers.
>
> .../platform/mediatek/jpeg/mtk_jpeg_core.c | 12 ++++++++-
> .../platform/mediatek/jpeg/mtk_jpeg_core.h | 14 +++++++++++
> .../platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 25 +++++++++++++------
> .../platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 25 +++++++++++++------
> 4 files changed, 61 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> index d147ec483081..d41c0e0516b9 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> @@ -1161,6 +1161,8 @@ static int mtk_jpeg_open(struct file *file)
> }
>
> INIT_WORK(&ctx->jpeg_work, jpeg->variant->jpeg_worker);
> + atomic_set(&ctx->hw_jobs, 0);
> + init_waitqueue_head(&ctx->hw_jobs_wq);
> INIT_LIST_HEAD(&ctx->dst_done_queue);
> spin_lock_init(&ctx->done_queue_lock);
> v4l2_fh_init(&ctx->fh, vfd);
> @@ -1202,8 +1204,12 @@ static int mtk_jpeg_release(struct file *file)
> struct mtk_jpeg_dev *jpeg = video_drvdata(file);
> struct mtk_jpeg_ctx *ctx = mtk_jpeg_file_to_ctx(file);
>
> - if (jpeg->variant->jpeg_worker)
> + if (jpeg->variant->jpeg_worker) {
> cancel_work_sync(&ctx->jpeg_work);
> + wait_event(ctx->hw_jobs_wq,
> + atomic_read(&ctx->hw_jobs) == 0);
> + }
> +
> mutex_lock(&jpeg->lock);
> v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
The things is that we already paid the price of this complexity in the m2m
framework by synchronously waiting for the last v4l2_m2m_job_finish() to be
called from the driver. I think we should not add a mechanism on top, but rather
figure-out why this is not working for your usage of this driver.
Nicolas
> v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
> @@ -1640,6 +1646,8 @@ static void mtk_jpegenc_worker(struct work_struct *work)
> v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>
> + atomic_inc(&ctx->hw_jobs);
> + atomic_set_release(&comp_jpeg[hw_id]->hw_param.job_active, 1);
> schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work,
> msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC));
>
> @@ -1759,6 +1767,8 @@ static void mtk_jpegdec_worker(struct work_struct *work)
> goto setdst_end;
> }
>
> + atomic_inc(&ctx->hw_jobs);
> + atomic_set_release(&comp_jpeg[hw_id]->hw_param.job_active, 1);
> schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work,
> msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC));
>
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
> index 02ed0ed5b736..be8ada60782a 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
> @@ -103,6 +103,7 @@ struct mtk_jpeg_hw_param {
> struct vb2_v4l2_buffer *src_buffer;
> struct vb2_v4l2_buffer *dst_buffer;
> struct mtk_jpeg_ctx *curr_ctx;
> + atomic_t job_active;
> };
>
> enum mtk_jpegenc_hw_id {
> @@ -282,6 +283,8 @@ struct mtk_jpeg_q_data {
> * @restart_interval: jpeg encoder restart interval
> * @ctrl_hdl: controls handler
> * @jpeg_work: jpeg encoder workqueue
> + * @hw_jobs: number of hardware jobs still referencing this context
> + * @hw_jobs_wq: wait queue for hardware job completion
> * @total_frame_num: encoded frame number
> * @dst_done_queue: encoded frame buffer queue
> * @done_queue_lock: encoded frame operation spinlock
> @@ -299,6 +302,8 @@ struct mtk_jpeg_ctx {
> struct v4l2_ctrl_handler ctrl_hdl;
>
> struct work_struct jpeg_work;
> + atomic_t hw_jobs;
> + wait_queue_head_t hw_jobs_wq;
> u32 total_frame_num;
> struct list_head dst_done_queue;
> /* spinlock protecting the encode done buffer */
> @@ -306,4 +311,13 @@ struct mtk_jpeg_ctx {
> u32 last_done_frame_num;
> };
>
> +static inline void
> +mtk_jpeg_hw_job_done(struct mtk_jpeg_hw_param *hw_param,
> + struct mtk_jpeg_ctx *ctx)
> +{
> + WRITE_ONCE(hw_param->curr_ctx, NULL);
> + if (atomic_dec_and_test(&ctx->hw_jobs))
> + wake_up(&ctx->hw_jobs_wq);
> +}
> +
> #endif /* _MTK_JPEG_CORE_H */
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
> index 32372781daf5..c2d40653891a 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
> @@ -527,7 +527,12 @@ static void mtk_jpegdec_timeout_work(struct work_struct *work)
> job_timeout_work.work);
> struct mtk_jpeg_dev *master_jpeg = cjpeg->master_dev;
> struct vb2_v4l2_buffer *src_buf, *dst_buf;
> + struct mtk_jpeg_ctx *ctx;
> +
> + if (atomic_cmpxchg(&cjpeg->hw_param.job_active, 1, 0) != 1)
> + return;
>
> + ctx = cjpeg->hw_param.curr_ctx;
> src_buf = cjpeg->hw_param.src_buffer;
> dst_buf = cjpeg->hw_param.dst_buffer;
> v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
> @@ -535,11 +540,13 @@ static void mtk_jpegdec_timeout_work(struct work_struct *work)
> mtk_jpeg_dec_reset(cjpeg->reg_base);
> clk_disable_unprepare(cjpeg->jdec_clk.clks->clk);
> pm_runtime_put(cjpeg->dev);
> + v4l2_m2m_buf_done(src_buf, buf_state);
> + mtk_jpegdec_put_buf(cjpeg);
> + mtk_jpeg_hw_job_done(&cjpeg->hw_param, ctx);
> +
> cjpeg->hw_state = MTK_JPEG_HW_IDLE;
> atomic_inc(&master_jpeg->hw_rdy);
> wake_up(&master_jpeg->hw_wq);
> - v4l2_m2m_buf_done(src_buf, buf_state);
> - mtk_jpegdec_put_buf(cjpeg);
> }
>
> static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
> @@ -555,12 +562,10 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
> struct mtk_jpegdec_comp_dev *jpeg = priv;
> struct mtk_jpeg_dev *master_jpeg = jpeg->master_dev;
>
> - cancel_delayed_work(&jpeg->job_timeout_work);
> + if (atomic_cmpxchg(&jpeg->hw_param.job_active, 1, 0) != 1)
> + return IRQ_HANDLED;
>
> - ctx = jpeg->hw_param.curr_ctx;
> - src_buf = jpeg->hw_param.src_buffer;
> - dst_buf = jpeg->hw_param.dst_buffer;
> - v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
> + cancel_delayed_work(&jpeg->job_timeout_work);
>
> irq_status = mtk_jpeg_dec_get_int_status(jpeg->reg_base);
> dec_irq_ret = mtk_jpeg_dec_enum_result(irq_status);
> @@ -570,6 +575,11 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
> if (dec_irq_ret != MTK_JPEG_DEC_RESULT_EOF_DONE)
> dev_warn(jpeg->dev, "Jpg Dec occurs unknown Err.");
>
> + ctx = jpeg->hw_param.curr_ctx;
> + src_buf = jpeg->hw_param.src_buffer;
> + dst_buf = jpeg->hw_param.dst_buffer;
> + v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
> +
> jpeg_src_buf =
> container_of(src_buf, struct mtk_jpeg_src_buf, b);
>
> @@ -582,6 +592,7 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
> mtk_jpegdec_put_buf(jpeg);
> pm_runtime_put(ctx->jpeg->dev);
> clk_disable_unprepare(jpeg->jdec_clk.clks->clk);
> + mtk_jpeg_hw_job_done(&jpeg->hw_param, ctx);
>
> jpeg->hw_state = MTK_JPEG_HW_IDLE;
> wake_up(&master_jpeg->hw_wq);
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
> index b312a15d707b..b08f94845613 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
> @@ -257,7 +257,12 @@ static void mtk_jpegenc_timeout_work(struct work_struct *work)
> struct mtk_jpeg_dev *master_jpeg = cjpeg->master_dev;
> enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> struct vb2_v4l2_buffer *src_buf, *dst_buf;
> + struct mtk_jpeg_ctx *ctx;
> +
> + if (atomic_cmpxchg(&cjpeg->hw_param.job_active, 1, 0) != 1)
> + return;
>
> + ctx = cjpeg->hw_param.curr_ctx;
> src_buf = cjpeg->hw_param.src_buffer;
> dst_buf = cjpeg->hw_param.dst_buffer;
> v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
> @@ -265,11 +270,13 @@ static void mtk_jpegenc_timeout_work(struct work_struct *work)
> mtk_jpeg_enc_reset(cjpeg->reg_base);
> clk_disable_unprepare(cjpeg->venc_clk.clks->clk);
> pm_runtime_put(cjpeg->dev);
> + v4l2_m2m_buf_done(src_buf, buf_state);
> + mtk_jpegenc_put_buf(cjpeg);
> + mtk_jpeg_hw_job_done(&cjpeg->hw_param, ctx);
> +
> cjpeg->hw_state = MTK_JPEG_HW_IDLE;
> atomic_inc(&master_jpeg->hw_rdy);
> wake_up(&master_jpeg->hw_wq);
> - v4l2_m2m_buf_done(src_buf, buf_state);
> - mtk_jpegenc_put_buf(cjpeg);
> }
>
> static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
> @@ -283,12 +290,10 @@ static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
> struct mtk_jpegenc_comp_dev *jpeg = priv;
> struct mtk_jpeg_dev *master_jpeg = jpeg->master_dev;
>
> - cancel_delayed_work(&jpeg->job_timeout_work);
> + if (atomic_cmpxchg(&jpeg->hw_param.job_active, 1, 0) != 1)
> + return IRQ_HANDLED;
>
> - ctx = jpeg->hw_param.curr_ctx;
> - src_buf = jpeg->hw_param.src_buffer;
> - dst_buf = jpeg->hw_param.dst_buffer;
> - v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
> + cancel_delayed_work(&jpeg->job_timeout_work);
>
> irq_status = readl(jpeg->reg_base + JPEG_ENC_INT_STS) &
> JPEG_ENC_INT_STATUS_MASK_ALLIRQ;
> @@ -297,6 +302,11 @@ static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
> if (!(irq_status & JPEG_ENC_INT_STATUS_DONE))
> dev_warn(jpeg->dev, "Jpg Enc occurs unknown Err.");
>
> + ctx = jpeg->hw_param.curr_ctx;
> + src_buf = jpeg->hw_param.src_buffer;
> + dst_buf = jpeg->hw_param.dst_buffer;
> + v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
> +
> result_size = mtk_jpeg_enc_get_file_size(jpeg->reg_base,
> ctx->jpeg->variant->support_34bit);
> vb2_set_plane_payload(&dst_buf->vb2_buf, 0, result_size);
> @@ -305,6 +315,7 @@ static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
> mtk_jpegenc_put_buf(jpeg);
> pm_runtime_put(ctx->jpeg->dev);
> clk_disable_unprepare(jpeg->venc_clk.clks->clk);
> + mtk_jpeg_hw_job_done(&jpeg->hw_param, ctx);
>
> jpeg->hw_state = MTK_JPEG_HW_IDLE;
> wake_up(&master_jpeg->hw_wq);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/8] clk: sunxi-ng: a733: Add PRCM CCU
From: Enzo Adriano @ 2026-07-18 14:46 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Philipp Zabel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
Jerome Brunet, linux-clk, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, netdev
In-Reply-To: <20260711-a733-clk-v2-3-974d188cbe0c@pigmoral.tech>
Hi Junhui,
I re-reviewed patch 3 in v2 after Andre pointed out that my RFC reply lacked
a formal tag.
I compared the RFC and v2 PRCM drivers and rechecked v2 against the Allwinner
A733 User Manual V0.92, chapter 4.2.5. I checked all 11 programmable clock
definitions (register offsets and divider/mux/gate fields), all 18 bus-gate
definitions, and all 13 reset-map entries. They match the manual.
The RFC-to-v2 changes do not invalidate that check: the four R timer clocks
move from the MP helper with no M field to the P-only helper while keeping
their offsets and P/mux/gate fields unchanged, and the R PWM identifiers are
renamed while keeping their offset/mux/gate fields unchanged. I also checked
the gate-only BGRs for R-TWD, R-PPU, R-TZMA, and R-CPU-BIST; the manual defines
gate bit 0 but no reset bit for those registers, matching v2.
Reviewed-by: Enzo Adriano <enzo.adriano.code@gmail.com>
This analysis was done with AI assistance and each finding was checked against
the cited sources.
Thanks,
Enzo
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: imx6ul-tx6ul: rename disp0 to display0
From: Frank.Li @ 2026-07-18 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, dri-devel,
Frank Li
In-Reply-To: <20260718-arm_dts_ldb-v2-0-f5669571aa2b@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Change node name disp0 to display0 to match binding define.
Fix the following CHECK_DTBS warning:
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul-0010.dtb: lcdif@21c8000 (fsl,imx6ul-lcdif): 'disp0' does not match any of the regexes: '^pinctrl-[0-9]+$'
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
index 192c6a95ae589..2f6916c0359c5 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
@@ -369,7 +369,7 @@ &lcdif {
display = <&display>;
status = "okay";
- display: disp0 {
+ display: display0 {
bits-per-pixel = <32>;
bus-width = <24>;
status = "okay";
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: display: lcdif: Allow display0 child node for i.MX6UL
From: Frank.Li @ 2026-07-18 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, dri-devel,
Frank Li
In-Reply-To: <20260718-arm_dts_ldb-v2-0-f5669571aa2b@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
The legacy i.MX6UL LCDIF binding uses a display0 child node to describe
the attached display. Update the binding schema to allow this child node
for fsl,imx6ul-lcdif.
Fixes the following CHECK_DTBS warning:
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul-0010.dtb: lcdif@21c8000 (fsl,imx6ul-lcdif): 'disp0' does not match any of the regexes: '^pinctrl-[0-9]+$'
A follow-up patch renames the child node from disp0 to display0 to match
the updated binding.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
sashiko report problem and allow dma/dma-names for i.MX6ul. which should
be fine for this kinds of old platform.
Ideally it should use port. but platform is too old to avoid break back
compatiblity and leave as it. Needn't complex if-else branch.
---
Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 2dd0411ec6516..2b123ddf06841 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -182,6 +182,7 @@ allOf:
contains:
enum:
- fsl,imx28-lcdif
+ - fsl,imx6ul-lcdif
then:
properties:
dmas: false
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: soc: imx-iomuxc-gpr: allow bridge@18 as child node
From: Frank.Li @ 2026-07-18 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, dri-devel,
Frank Li
In-Reply-To: <20260718-arm_dts_ldb-v2-0-f5669571aa2b@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
The legacy i.MX6SX (>15 year) SoC imx-iomuxc-gpr contains one LDB_CTRL
register. Allow the LVDS Display Bridge(LDB) child node under
imx-iomuxc-gpr.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6sx-nitrogen6sx.dtb: syscon@20e4000 (fsl,imx6sx-iomuxc-gpr): '#address-cells', '#size-cells', 'bridge@18' do not match any of the regexes: '^ipu[12]_csi[01]_mux$', '^pinctrl-[0-9]+$
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
changes in v2
- remote status = "disabled" in example
---
.../bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml | 58 ++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
index 721a67e84c137..1879638918bab 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
@@ -47,10 +47,21 @@ properties:
reg:
maxItems: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
mux-controller:
type: object
$ref: /schemas/mux/reg-mux.yaml
+ bridge@18:
+ type: object
+ $ref: /schemas/display/bridge/fsl,ldb.yaml#
+ unevaluatedProperties: false
+
patternProperties:
"^ipu[12]_csi[01]_mux$":
type: object
@@ -67,6 +78,18 @@ allOf:
patternProperties:
'^ipu[12]_csi[01]_mux$': false
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: fsl,imx6sx-iomuxc-gpr
+ then:
+ properties:
+ bridge@18: false
+ '#address-cells': false
+ '#size-cells': false
+
additionalProperties: false
required:
@@ -87,4 +110,39 @@ examples:
};
};
+ - |
+ #include <dt-bindings/clock/imx6sx-clock.h>
+
+ syscon@20e4000 {
+ compatible = "fsl,imx6sx-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd";
+ reg = <0x020e4000 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bridge@18 {
+ compatible = "fsl,imx6sx-ldb";
+ reg = <0x18 0x4>;
+ clocks = <&clks IMX6SX_CLK_LDB_DI0>;
+ clock-names = "ldb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ };
+ };
+ };
+ };
+ };
...
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: display: bridge: ldb: allow a single reg for fsl,imx6sx-ldb
From: Frank.Li @ 2026-07-18 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, dri-devel,
Frank Li
In-Reply-To: <20260718-arm_dts_ldb-v2-0-f5669571aa2b@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
The i.MX6SX LDB only provides a single register region for the LDB block,
while other supported LDB variants require two register regions.
Update the binding schema to allow a single reg entry for
fsl,imx6sx-ldb while keeping the existing constraints unchanged for the
other compatible strings.
Fix below DTB_CHECK warings:
arch/arm/boot/dts/nxp/imx/imx6sx-nitrogen6sx.dtb: bridge@18 (fsl,imx6sx-ldb): reg: [[24, 4]] is too short
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Related two theads:
- https://lore.kernel.org/imx/178154922879.1630652.11500293336634076421.robh@kernel.org/
Mixing the addressable and non-addressable child nodes is allowed according to discussion [1].
Link: https://lore.kernel.org/all/n6akxiayi3g6gxcqhreb4iaohmeokoalnqup6h5r2fwdt4zijt@u2wyps55ayqm/ [1]
---
.../bindings/display/bridge/fsl,ldb.yaml | 23 +++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
index 7f380879fffdf..e5a8870bb76a6 100644
--- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
@@ -28,9 +28,11 @@ properties:
const: ldb
reg:
+ minItems: 1
maxItems: 2
reg-names:
+ minItems: 1
items:
- const: ldb
- const: lvds
@@ -83,15 +85,6 @@ allOf:
ports:
properties:
port@2: false
- - if:
- not:
- properties:
- compatible:
- contains:
- const: fsl,imx6sx-ldb
- then:
- required:
- - reg-names
- if:
properties:
@@ -100,7 +93,19 @@ allOf:
const: fsl,imx6sx-ldb
then:
properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ maxItems: 1
nxp,enable-termination-resistor: false
+ else:
+ required:
+ - reg-names
+ properties:
+ reg:
+ minItems: 2
+ reg-names:
+ minItems: 2
additionalProperties: false
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] ARM: dts: imx: fix ldb related CHECK_DTBS warnings
From: Frank.Li @ 2026-07-18 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, dri-devel,
Frank Li
Fix ldb related CHECK_DTBS warnings
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
- Remove status = disabled at binding example
- collect rob's reviewed-by tags.
- Link to v1: https://patch.msgid.link/20260708-arm_dts_ldb-v1-0-4f5579b85797@nxp.com
---
Frank Li (4):
dt-bindings: display: bridge: ldb: allow a single reg for fsl,imx6sx-ldb
dt-bindings: soc: imx-iomuxc-gpr: allow bridge@18 as child node
dt-bindings: display: lcdif: Allow display0 child node for i.MX6UL
ARM: dts: imx6ul-tx6ul: rename disp0 to display0
.../bindings/display/bridge/fsl,ldb.yaml | 23 +++++----
.../devicetree/bindings/display/fsl,lcdif.yaml | 1 +
.../bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml | 58 ++++++++++++++++++++++
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
4 files changed, 74 insertions(+), 10 deletions(-)
---
base-commit: 6c94b38b83a04c43ea49004275f0391404051093
change-id: 20260708-arm_dts_ldb-9ca4c548dded
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH net-next] net: stmmac: Simplify ioctl handling
From: Maxime Chevallier @ 2026-07-18 14:38 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré, netdev,
linux-kernel, linux-arm-kernel, linux-stm32
Now that timestamping is controlled through an NDO, we can simply
call phylink_mii_ioctl() to handle ioctls.
The only functional difference is that phylink_mii_ioctl() ->
phy_mii_ioctl() can handle SIOCSHWTSTAMP, but this no longer happens
as this ioctl is not longer dispatched to the ndo_eth_ioctl().
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
handling in phy_mii_ioctl(). Looks like we can ?
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..562d20830b94 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6371,28 +6371,17 @@ static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
* @rq: An IOCTL specific structure, that can contain a pointer to
* a proprietary structure used to pass information to the driver.
* @cmd: IOCTL command
- * Description:
- * Currently it supports the phy_mii_ioctl(...) and HW time stamping.
+ * Description: Forward the PHY ioctls to phylink
+ * Return: Zero on success or negative error code.
*/
static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct stmmac_priv *priv = netdev_priv (dev);
- int ret = -EOPNOTSUPP;
if (!netif_running(dev))
return -EINVAL;
- switch (cmd) {
- case SIOCGMIIPHY:
- case SIOCGMIIREG:
- case SIOCSMIIREG:
- ret = phylink_mii_ioctl(priv->phylink, rq, cmd);
- break;
- default:
- break;
- }
-
- return ret;
+ return phylink_mii_ioctl(priv->phylink, rq, cmd);
}
static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
--
2.55.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox