* [PATCH] media: imx-jpeg: finish the job on device_run() error paths
From: Fan Wu @ 2026-06-24 0:32 UTC (permalink / raw)
To: mirela.rabulea, mchehab
Cc: shawnguo, s.hauer, kernel, festevam, imx, linux-media,
linux-arm-kernel, linux-kernel, stable, Fan Wu
mxc_jpeg_device_run() returns early through a shared "end" label on several
error paths (no free slot, mxc_jpeg_alloc_slot_data() failure, or missing
buffers or queue data), and none of them calls v4l2_m2m_job_finish().
Since the delayed work is queued only after the hardware is started, those
paths neither finish the job directly nor queue timeout work that could
finish it later. The job is left with TRANS_RUNNING set, so the
wait_event() in v4l2_m2m_cancel_job() (reached from v4l2_m2m_ctx_release()
at close) waits indefinitely and the close hangs.
mxc_jpeg_alloc_slot_data() uses dma_alloc_coherent(), so the failure path
is reachable under memory pressure.
Return the src/dst buffers with VB2_BUF_STATE_ERROR and call
v4l2_m2m_job_finish() on those paths: paths that have buffers use a
"buf_finish" label; the no-buffer path uses "job_finish" directly. This
mirrors the existing jpeg_parse_error path.
This bug was found by static analysis.
Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Cc: stable@vger.kernel.org
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
.../media/platform/nxp/imx-jpeg/mxc-jpeg.c | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
index 9e4a813489c0..6b224a19f40e 100644
--- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
+++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
@@ -1525,15 +1525,15 @@ static void mxc_jpeg_device_run(void *priv)
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
if (!src_buf || !dst_buf) {
dev_err(dev, "Null src or dst buf\n");
- goto end;
+ goto job_finish;
}
q_data_cap = mxc_jpeg_get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
if (!q_data_cap)
- goto end;
+ goto buf_finish;
q_data_out = mxc_jpeg_get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
if (!q_data_out)
- goto end;
+ goto buf_finish;
src_buf->sequence = q_data_out->sequence++;
dst_buf->sequence = q_data_cap->sequence++;
@@ -1571,11 +1571,11 @@ static void mxc_jpeg_device_run(void *priv)
ctx->slot = mxc_get_free_slot(&jpeg->slot_data);
if (ctx->slot < 0) {
dev_err(dev, "No more free slots\n");
- goto end;
+ goto buf_finish;
}
if (!mxc_jpeg_alloc_slot_data(jpeg)) {
dev_err(dev, "Cannot allocate slot data\n");
- goto end;
+ goto buf_finish;
}
mxc_jpeg_enable_slot(reg, ctx->slot);
@@ -1597,8 +1597,17 @@ static void mxc_jpeg_device_run(void *priv)
mxc_jpeg_dec_mode_go(dev, reg);
}
schedule_delayed_work(&ctx->task_timer, msecs_to_jiffies(hw_timeout));
-end:
+
spin_unlock_irqrestore(&ctx->mxc_jpeg->hw_lock, flags);
+ return;
+buf_finish:
+ v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_ERROR);
+ v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_ERROR);
+job_finish:
+ spin_unlock_irqrestore(&ctx->mxc_jpeg->hw_lock, flags);
+ v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
}
static int mxc_jpeg_decoder_cmd(struct file *file, void *priv,
--
2.34.1
^ permalink raw reply related
* [arm64:for-next/core 12/12] usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
From: kernel test robot @ 2026-06-24 2:14 UTC (permalink / raw)
To: Will Deacon; +Cc: oe-kbuild-all, linux-arm-kernel, Marc Zyngier, Arnd Bergmann
Hi Will,
FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
head: 9d6306113f921dc00793df46f31ed46583c720df
commit: 9d6306113f921dc00793df46f31ed46583c720df [12/12] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
config: arm64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260624/202606240441.7eZ1TIRM-lkp@intel.com/config)
compiler: aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260624/202606240441.7eZ1TIRM-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606240441.7eZ1TIRM-lkp@intel.com/
Note: the arm64/for-next/core HEAD 9d6306113f921dc00793df46f31ed46583c720df builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from testcases/fake_sigreturn_bad_magic.c:10:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from ./test_signals.h:14,
from ./test_signals_utils.h:14,
from testcases/fake_sigreturn_bad_magic.c:13:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from test_signals.h:7,
from test_signals.c:16:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from test_signals.h:14:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from test_signals_utils.c:6:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from test_signals.h:14,
from test_signals_utils.c:18:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from testcases/testcases.h:12,
from testcases/testcases.c:7:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from sve_helpers.c:10:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from /usr/aarch64-linux-gnu/include/sys/wait.h:36,
from pac.c:8:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from /usr/aarch64-linux-gnu/include/sys/wait.h:36,
from fp-ptrace.c:22:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from fp-ptrace.c:28:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from mte_common_util.h:7,
from check_buffer_fill.c:11:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from mte_common_util.c:6:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from system.h:20,
from test.c:7:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from test.c:14:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from system.h:20,
from signal.c:7:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from tools/testing/selftests/cgroup/lib/cgroup_util.c:9:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
cc1: note: unrecognized command-line option '-Wno-gnu-variable-sized-type-not-at-end' may have been intended to silence earlier diagnostics
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from include/test_util.h:12,
from include/kvm_util.h:8,
from demand_paging_test.c:17:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from usr/include/asm/kvm.h:37,
from usr/include/linux/kvm.h:16,
from include/kvm_util.h:14:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
cc1: note: unrecognized command-line option '-Wno-gnu-variable-sized-type-not-at-end' may have been intended to silence earlier diagnostics
--
In file included from usr/include/asm/kvm.h:37,
from usr/include/linux/kvm.h:16,
from lib/arm64/gic_v3_its.c:7:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from include/test_util.h:12,
from include/kvm_util.h:8,
from lib/arm64/gic_v3_its.c:12:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
cc1: note: unrecognized command-line option '-Wno-gnu-variable-sized-type-not-at-end' may have been intended to silence earlier diagnostics
..
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] mmc: cqhci: Remove unused intmask parameter from cqhci_irq()
From: Chanwoo Lee @ 2026-06-24 2:19 UTC (permalink / raw)
To: Adrian Hunter, Asutosh Das, Ritesh Harjani, Ulf Hansson,
Chaotian Jing, Matthias Brugger, AngeloGioacchino Del Regno,
Kamal Dasu, Al Cooper, Broadcom internal kernel review list,
Florian Fainelli, Haibo Chen, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Michal Simek,
Thierry Reding, Jonathan Hunter,
open list:EMMC CMDQ HOST CONTROLLER INTERFACE (CQHCI) DRIVER,
open list, moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
open list:ARM/QUALCOMM MAILING LIST,
open list:TEGRA ARCHITECTURE SUPPORT
Cc: Chanwoo Lee
In-Reply-To: <CGME20260624021955epcas1p2ba2fa4eb8bd0aafaf7b46bde2cf524be@epcas1p2.samsung.com>
The intmask parameter of cqhci_irq() is never used within the function
body. The function reads the CQHCI interrupt status directly via
cqhci_readl() and processes interrupts independently of the SDHCI
intmask value passed by callers.
Signed-off-by: Chanwoo Lee <cw9316.lee@samsung.com>
---
drivers/mmc/host/cqhci-core.c | 3 +--
drivers/mmc/host/cqhci.h | 3 +--
drivers/mmc/host/mtk-sd.c | 2 +-
drivers/mmc/host/sdhci-brcmstb.c | 2 +-
drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
drivers/mmc/host/sdhci-msm.c | 2 +-
drivers/mmc/host/sdhci-of-arasan.c | 2 +-
drivers/mmc/host/sdhci-of-dwcmshc.c | 2 +-
drivers/mmc/host/sdhci-pci-core.c | 2 +-
drivers/mmc/host/sdhci-pci-gli.c | 2 +-
drivers/mmc/host/sdhci-tegra.c | 2 +-
drivers/mmc/host/sdhci_am654.c | 2 +-
12 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/cqhci-core.c b/drivers/mmc/host/cqhci-core.c
index 178277d90c31..98ceb0b9a6d1 100644
--- a/drivers/mmc/host/cqhci-core.c
+++ b/drivers/mmc/host/cqhci-core.c
@@ -819,8 +819,7 @@ static void cqhci_finish_mrq(struct mmc_host *mmc, unsigned int tag)
mmc_cqe_request_done(mmc, mrq);
}
-irqreturn_t cqhci_irq(struct mmc_host *mmc, u32 intmask, int cmd_error,
- int data_error)
+irqreturn_t cqhci_irq(struct mmc_host *mmc, int cmd_error, int data_error)
{
u32 status;
unsigned long tag = 0, comp_status;
diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h
index 3668856531c1..8fbbc48c3f85 100644
--- a/drivers/mmc/host/cqhci.h
+++ b/drivers/mmc/host/cqhci.h
@@ -315,8 +315,7 @@ static inline u32 cqhci_readl(struct cqhci_host *host, int reg)
struct platform_device;
-irqreturn_t cqhci_irq(struct mmc_host *mmc, u32 intmask, int cmd_error,
- int data_error);
+irqreturn_t cqhci_irq(struct mmc_host *mmc, int cmd_error, int data_error);
int cqhci_init(struct cqhci_host *cq_host, struct mmc_host *mmc, bool dma64);
struct cqhci_host *cqhci_pltfm_init(struct platform_device *pdev);
int cqhci_deactivate(struct mmc_host *mmc);
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b2680cc054bd..01ea3adbdf3b 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1805,7 +1805,7 @@ static irqreturn_t msdc_cmdq_irq(struct msdc_host *host, u32 intsts)
cmd_err, dat_err, intsts);
}
- return cqhci_irq(mmc, 0, cmd_err, dat_err);
+ return cqhci_irq(mmc, cmd_err, dat_err);
}
static irqreturn_t msdc_irq(int irq, void *dev_id)
diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index 57e45951644e..1de2f05fd958 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -430,7 +430,7 @@ static u32 sdhci_brcmstb_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 18ecddd6df6f..d0fa83f67a80 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1503,7 +1503,7 @@ static u32 esdhc_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 0882ce74e0c9..ceed47ccfda8 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -2165,7 +2165,7 @@ static u32 sdhci_msm_cqe_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 785d3acb18c5..4ca73e7d799e 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -555,7 +555,7 @@ static u32 sdhci_arasan_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c b/drivers/mmc/host/sdhci-of-dwcmshc.c
index eef53455b8ee..4c5fa6a6931d 100644
--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
+++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
@@ -624,7 +624,7 @@ static u32 dwcmshc_cqe_irq_handler(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index c347fac24515..b121d896a804 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -215,7 +215,7 @@ static u32 sdhci_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index 6e4084407662..b55618566d65 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -1760,7 +1760,7 @@ static u32 sdhci_gl9763e_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 820ce4dae58b..221e48b59f48 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1280,7 +1280,7 @@ static u32 sdhci_tegra_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index d235b0aecfdb..2a27db2f558b 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -462,7 +462,7 @@ static u32 sdhci_am654_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
From: Bui Duc Phuc @ 2026-06-24 2:37 UTC (permalink / raw)
To: Mark Brown
Cc: Heiko Stuebner, Liam Girdwood, Nicolas Frattaroli,
Krzysztof Kozlowski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <CAABR9nG6BL+-urEg0qDzJHYmowm7O=du_0T4+K2ogdrcD30CXA@mail.gmail.com>
Hi all,
Regarding the case where PM configuration is not enabled, with the old
source code, I suspect there is an unbalanced clk_disable_unprepare()
call on hclk when the driver is unbound after a successful probe under
CONFIG_PM=n.
The actual enable_count / prepare_count sequence for hclk (with values
clamped at 0) would be:
probe:
devm_clk_get_enabled 0 -> 1
runtime_resume (manual) 1 -> 2
clk_disable_unprepare 2 -> 1 (at the end of probe)
unbind:
remove -> runtime_suspend 1 -> 0 (ops->disable/unprepare executed here)
devm cleanup 0 -> WARN "already disabled" /
"already unprepared"
This conclusion is based solely on code inspection; I do not have
hardware available to verify it.
I noticed that Nicolas tested and ACKed the use of devm_clk_get_enabled(),
so I'm not sure whether that testing included the CONFIG_PM=n configuration.
https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
If it did, then I may have overlooked something.
@Nicolas (or anyone familiar with this), could you please help
double-check if my understanding is correct?
Best regards,
Phuc
On Tue, Jun 23, 2026 at 5:53 PM Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
>
> Hi Mark,
>
> Thank you for your review.
>
> > > 1 Reverting back to devm_clk_get() to remove the implicit devres
> > > enable/disable behavior.
> > > 2 Manually enabling and disabling hclk explicitly only around the
> > > early register access before Runtime PM takes over.
> > > 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> > > so Runtime PM solely owns hclk afterward.
> >
> > Note that runtime PM can be disabled at build time so we might not have
> > runtime PM at all...
> >
>
> Thanks for pointing this out. You're right that with !CONFIG_PM, the
> driver only relies on the
> two manual calls to rokchip_sai_runtime_resume() / suspend(), so hclk
> stays enabled the
> whole time. I understand this is unvavoidable in that configuration,
> throgh, since there's no
> Runtime PM to re-enable the clock when it's needed.
>
> I'll update the commit message to reflect that the driver uses a
> combination of Runtime PM
> and explicit manual enable/disable, rather than relying on Runtime PM alone.
>
> > > Links:
> > > 1 This change is based on the discussion around manual hclk handing during probe(),
> > > as raised by Krysztof:
> > > https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> > > 2 Background for the earlier devm_clk_get_enbabled() conversion:
> > > https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
> >
> > > An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> > > manage clock enablement around register accesses. If preferred, I can rework the
> > > driver accordingly.
> >
> > > - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> > > + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> > > if (IS_ERR(sai->hclk))
> > > return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> > > "Failed to get hclk\n");
> > >
> > > + ret = clk_prepare_enable(sai->hclk);
> > > + if (ret)
> > > + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> > > +
> >
> > > @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> > > pm_runtime_use_autosuspend(&pdev->dev);
> > > pm_runtime_put(&pdev->dev);
> > >
> > > - clk_disable_unprepare(sai->hclk);
> > > -
> > > return 0;
> >
> > Are you sure that the runtime PM state there is such that it knows a
> > reference is held? The driver used pm_runtime_get_noresume() so the
> > device didn't have RPM_ACTIVE set I think?
>
>
> You are right, pm_runtime_get_noresume() doesn't set RPM_ACTIVE. I
> think we need to add
> pm_runtime_set_active() before pm_runtime_enable(). Otherwise, with CONFIG_PM,
> the pm_runtime_put() at the end of probe() might skip the suspend,
> since the core still considers
> the device suspended .
>
> >
> > The runtime PM API really is a miserable collection of landmines :(
>
> Yeah, plenty of landmines indeed :(
> I checked, and rockchip_spdif.c does use devm_regmap_init_mmio_clk() for hclk,
> rather than wrapping every register access in pm_runtime_get_sync() /
> pm_runtime_put()
> the way rockchip_sai does.
>
> Best regards,
> Phuc
^ permalink raw reply
* Re: chipidea: usbmisc_imx: i.MX93 support
From: Xu Yang @ 2026-06-24 2:50 UTC (permalink / raw)
To: Stefan Wahren
Cc: Xu Yang, Frank Li, Jun Li, Alexander Stein, Greg Kroah-Hartman,
Linux ARM, linux-usb@vger.kernel.org
In-Reply-To: <b2fb88eb-5c5f-499f-9cee-6a69769c578c@gmx.net>
On Tue, Jun 23, 2026 at 12:23:12PM +0200, Stefan Wahren wrote:
> Hi,
>
> during debugging USB OTG on our custom i.MX93 board, we noticed remarkable
> differences between the implementation of the chipidea/usbmisc_imx and the
> official NXP i.MX93 Reference Manual [1].
>
> Is the USB OTG part including PHY of the i.MX93 officially supported in
> Linux Mainline?
Yes.
>
> According to imx91_93_common.dtsi the USB IP of the i.MX93 should be
> identical to i.MX8MM [2]
>
> usbmisc1: usbmisc@4c100200 {
>
> compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
> "fsl,imx6q-usbmisc";
>
> But looking at the PHY register definition and reset values in the NXP
> i.MX93 Reference Manual,
>
> the registers are comparable to the i.MX95 [3] ones.
>
> Could you please clarify which source is correct (Mainline DTS vs Reference
> Manual)?
The Reference Manual is correct.
>
> Looking deeper at chipidea/usbmisc_imx shows the usage of the following
> register bits
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_CHRGSEL BIT(0)
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATDETENB0 BIT(1)
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATSRCENB0 BIT(2)
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_DCDENB BIT(3)
>
> #define MX7D_USB_OTG_PHY_STATUS_LINE_STATE0 BIT(0)
>
> #define MX7D_USB_OTG_PHY_STATUS_LINE_STATE1 BIT(1)
>
> #define MX7D_USB_OTG_PHY_STATUS_CHRGDET BIT(29)
>
> According to NXP i.MX93 & i.MX95 Reference Manual, these are bits reserved.
>
> Is it correct that the chipidea/usbmisc_imx use these bits on i.MX93?
i.MX93 & i.MX95 no longer claims to support Battery charger detection. So these
bits are reserved. However, at the IP level, accessing these bits will not produce
errors. We will remove .charger_detection hook for the i.MX9 series in the future.
Do you want to use Battery charger detection on i.MX93?
Thanks,
Xu Yang
>
> Best regards
>
> [1] - https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf
> <https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf>
>
> [2] - https://www.nxp.com/docs/en/reference-manual/IMX8MMRM.pdf
> <https://www.nxp.com/docs/en/reference-manual/IMX8MMRM.pdf>
>
> [3] - https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf
> <https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf>
>
^ permalink raw reply
* RE: [PATCH 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: G.N. Zhou @ 2026-06-24 2:54 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-1-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 1/4] device property: Introduce
> fwnode_graph_for_each_endpoint_scoped()
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Similar to recently propose for_each_child_of_node_scoped() this new version
> of the loop macro instantiates a new local struct fwnode_handle * that uses the
> __free(fwnode_handle) auto cleanup handling so that if a reference to a node is
> held on early exit from the loop the reference will be released. If the loop runs
> to completion, the child pointer will be NULL and no action will be taken.
>
> The reason this is useful is that it removes the need for
> fwnode_handle_put() on early loop exits. If there is a need to retain the
> reference, then return_ptr(child) or no_free_ptr(child) may be used to safely
> disable the auto cleanup.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> include/linux/property.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/property.h b/include/linux/property.h index
> 14c304db46648..ade194c462d42 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -545,6 +545,11 @@ unsigned int
> fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
> for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child;
> \
> child = fwnode_graph_get_next_endpoint(fwnode, child))
>
> +#define fwnode_graph_for_each_endpoint_scoped(fwnode, child)
> \
> + for (struct fwnode_handle *child __free(fwnode_handle) =
> \
> + fwnode_graph_get_next_endpoint(fwnode, NULL);
> \
> + child; child = fwnode_graph_get_next_endpoint(fwnode, child))
> +
> int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> struct fwnode_endpoint *endpoint);
>
>
> --
> 2.43.0
^ permalink raw reply
* [RFC PATCH] irqchip/gic-v3-its: enable dynamic MSI-X allocation
From: Jinqian Yang @ 2026-06-24 2:53 UTC (permalink / raw)
To: lpieralisi, maz, tglx, alex
Cc: linux-kernel, linux-arm-kernel, liuyonglong, wangzhou1, linuxarm,
Jinqian Yang
On ARM64 platforms with GICv3 ITS, VFIO PCI passthrough currently
cannot dynamically allocate MSI-X vectors after MSI-X has been
enabled. When QEMU needs to extend the vector range, it must
disable MSI-X, free all interrupts, then re-enable with a larger
allocation. This creates an interrupt loss window for already-active
vectors.
Consider HNS3 with RoCE: NIC and RDMA share one PCI device and
ITS DeviceID, with MSI-X vectors partitioned as NIC (lower range)
then RoCE (starting at base_vector = num_nic_msi). In VFIO
passthrough, loading hns_roce after hns3 forces QEMU to tear down
all interrupts before re-allocating the larger range. During this
process, NIC interrupts may be lost. Testing confirmed that this
occasionally occurs, causing the network port reset to fail.
ITS_MSI_FLAGS_SUPPORTED lacks MSI_FLAG_PCI_MSIX_ALLOC_DYN, causing
pci_msix_can_alloc_dyn() to return false. VFIO then sets
has_dyn_msix=false and never clears VFIO_IRQ_INFO_NORESIZE for
MSI-X, keeping the old "disable and reallocate" behavior.
The essential prerequisite for enabling this flag is the fix to
msi_prepare() call timing (commit 1396e89e09f0 ("genirq/msi: Move
prepare() call to per-device allocation")): msi_prepare() is
now called once at per-device domain creation with hwsize, so ITS
creates an ITT with sufficient capacity for all MSI-X vectors.
Without this fix, msi_prepare() was called per-allocation with
semi-random nvec, maybe resulting in an ITT too small for dynamic
vector addition.
With this in place, dynamic MSI-X allocation works correctly:
msi_domain_alloc_irq_at() uses populate_alloc_info() to copy the
pre-prepared alloc_data without re-invoking msi_prepare(), so each
new vector simply gets a LPI entry in the already-allocated ITT,
without affecting existing vectors.
Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com>
---
drivers/irqchip/irq-gic-its-msi-parent.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c
index b9257103a999..b2b9d2068bb1 100644
--- a/drivers/irqchip/irq-gic-its-msi-parent.c
+++ b/drivers/irqchip/irq-gic-its-msi-parent.c
@@ -18,7 +18,8 @@
#define ITS_MSI_FLAGS_SUPPORTED (MSI_GENERIC_FLAGS_MASK | \
MSI_FLAG_PCI_MSIX | \
- MSI_FLAG_MULTI_PCI_MSI)
+ MSI_FLAG_MULTI_PCI_MSI | \
+ MSI_FLAG_PCI_MSIX_ALLOC_DYN)
static int its_translate_frame_address(struct fwnode_handle *msi_node, phys_addr_t *pa)
{
--
2.33.0
^ permalink raw reply related
* RE: [PATCH 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: G.N. Zhou @ 2026-06-24 3:15 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-2-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 2/4] media: mc: use
> fwnode_graph_for_each_endpoint_scoped() to simpilfy code
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
s/simpifly/simplify/ both in message title and body.
With this addressed:
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> code.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-
> mc.c
> index 937d358697e19..5d7fcd67dc42e 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -324,12 +324,10 @@
> EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
> int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> struct media_pad *sink, u32 flags) {
> - struct fwnode_handle *endpoint;
> -
> if (!(sink->flags & MEDIA_PAD_FL_SINK))
> return -EINVAL;
>
> - fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
> + fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint)
> {
> struct fwnode_handle *remote_ep;
> int src_idx, sink_idx, ret;
> struct media_pad *src;
> @@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct
> v4l2_subdev *src_sd,
> src_sd->entity.name, src_idx,
> sink->entity->name, sink_idx, ret);
>
> - fwnode_handle_put(endpoint);
> return ret;
> }
> }
>
> --
> 2.43.0
^ permalink raw reply
* RE: [PATCH 4/4] media: qcom: camss: use fwnode_graph_for_each_endpoint_scoped() to simpifly code
From: G.N. Zhou @ 2026-06-24 3:17 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-4-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 4/4] media: qcom: camss: use
> fwnode_graph_for_each_endpoint_scoped() to simpifly code
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Use fwnode_graph_for_each_endpoint_scoped() to simpifly code.
s/simpifly/simplify/ both in message title and body.
With this addressed:
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
>
> No functional changes.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/media/platform/qcom/camss/camss.c | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss.c
> b/drivers/media/platform/qcom/camss/camss.c
> index 2123f6388e3d7..23f3cc30a15a5 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -4793,30 +4793,23 @@ static int camss_parse_endpoint_node(struct
> device *dev, static int camss_parse_ports(struct camss *camss) {
> struct device *dev = camss->dev;
> - struct fwnode_handle *fwnode = dev_fwnode(dev), *ep;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> int ret;
>
> - fwnode_graph_for_each_endpoint(fwnode, ep) {
> + fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
> struct camss_async_subdev *csd;
>
> csd = v4l2_async_nf_add_fwnode_remote(&camss->notifier,
> ep,
> typeof(*csd));
> - if (IS_ERR(csd)) {
> - ret = PTR_ERR(csd);
> - goto err_cleanup;
> - }
> + if (IS_ERR(csd))
> + return PTR_ERR(csd);
>
> ret = camss_parse_endpoint_node(dev, ep, csd);
> if (ret < 0)
> - goto err_cleanup;
> + return ret;
> }
>
> return 0;
> -
> -err_cleanup:
> - fwnode_handle_put(ep);
> -
> - return ret;
> }
>
> /*
>
> --
> 2.43.0
^ permalink raw reply
* [PATCH v2] cpufreq: apple-soc: Fix OPP table cleanup
From: Haoxiang Li @ 2026-06-24 3:37 UTC (permalink / raw)
To: sven, j, neal, rafael, viresh.kumar
Cc: linux-arm-kernel, asahi, linux-pm, linux-kernel, Haoxiang Li
dev_pm_opp_of_add_table() adds the DT OPP table but not all failure
paths remove it. The driver also uses dev_pm_opp_remove_all_dynamic(),
which is not the right cleanup helper for OPPs loaded from firmware.
Remove the DT OPP table with dev_pm_opp_of_remove_table() on init
failure paths and from apple_soc_cpufreq_exit().
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
Changes in v2:
- Remove unnecessary cleanup calls.
- Remove OPP table from apple_soc_cpufreq_exit(). Thanks, Viresh!
---
drivers/cpufreq/apple-soc-cpufreq.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c
index 638e5bf72185..977d56fc4fa0 100644
--- a/drivers/cpufreq/apple-soc-cpufreq.c
+++ b/drivers/cpufreq/apple-soc-cpufreq.c
@@ -258,7 +258,7 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
ret = apple_soc_cpufreq_find_cluster(policy, ®_base, &info);
if (ret) {
dev_err(cpu_dev, "%s: failed to get cluster info: %d\n", __func__, ret);
- return ret;
+ goto out_remove_opp_table;
}
ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
@@ -271,13 +271,13 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
if (ret <= 0) {
dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
ret = -EPROBE_DEFER;
- goto out_free_opp;
+ goto out_iounmap;
}
priv = kzalloc_obj(*priv);
if (!priv) {
ret = -ENOMEM;
- goto out_free_opp;
+ goto out_iounmap;
}
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
@@ -320,10 +320,10 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
out_free_priv:
kfree(priv);
-out_free_opp:
- dev_pm_opp_remove_all_dynamic(cpu_dev);
out_iounmap:
iounmap(reg_base);
+out_remove_opp_table:
+ dev_pm_opp_of_remove_table(cpu_dev);
return ret;
}
@@ -332,7 +332,7 @@ static void apple_soc_cpufreq_exit(struct cpufreq_policy *policy)
struct apple_cpu_priv *priv = policy->driver_data;
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
- dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
+ dev_pm_opp_of_remove_table(priv->cpu_dev);
iounmap(priv->reg_base);
kfree(priv);
}
--
2.25.1
^ permalink raw reply related
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-06-24 3:59 UTC (permalink / raw)
To: Shulzhenko, Oleksandr, Arnd Bergmann, Andrew Jeffery,
Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB4276452D09689C90B04209C190EF2@KL1PR0601MB4276.apcprd06.prod.outlook.com>
Hi Mark,
> (1) Reuse the existing SPI subsystem and treat eSPI packets as pure signals.
> (2) Maintain the driver under the SoC subsystem, since there is currently no
> eSPI subsystem.
> (3) Create a new eSPI subsystem and rewrite the eSPI driver accordingly.
>
> For option 1, we do not think this would be a good fit, because eSPI has clearly
> defined semantics for each channel, and our hardware exposes different sets of
> registers for each of them.
Regarding option 1, could you kindly share your feedback on whether this
patch set should be modified to fit under the SPI subsystem, or whether a new
eSPI subsystem would be more appropriate?
For option 2, Arnd has indicated that he does not want to take this through
the SoC subsystem. Therefore, if the SPI subsystem is also not a good fit, we
think a new eSPI subsystem may be needed to provide a common home for channel
handling, even though the individual channels are relatively independent.
For example, the VW and OOB channel handling could potentially be integrated
with existing subsystems such as GPIO or net/mctp. However, the Flash channel
would still need an eSPI-specific interface to configure the backing store.
Placing that code under MTD feels awkward, since the driver is not really an
MTD device or a flash controller.
If this direction sounds reasonable, we would like to explore introducing a
new drivers/espi subsystem and moving the eSPI driver there. Please let us
know if you think we should take a different approach.
Thanks,
Yun Hsuan.
^ permalink raw reply
* Re: [PATCH] Input: mtk-pmic-keys: Count available keys during probe instead of pre-counting
From: Dmitry Torokhov @ 2026-06-24 4:14 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-input, Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20260528235600.312045-1-rosenp@gmail.com>
Hi Rosen,
On Thu, May 28, 2026 at 04:56:00PM -0700, Rosen Penev wrote:
> Replace the separate of_get_available_child_count() pre-count and
> validation step with a single pass through for_each_child_of_node_scoped().
> Skip unavailable child nodes and bail out if more than
> MTK_PMIC_MAX_KEY_COUNT available keys are found. Set nkeys after the
> loop so suspend/resume iterate only over initialized entries.
>
> Also use a key variable in the loop for clarity.
>
> Use of_device_get_match_data() to fetch the PMIC key register data directly
> instead of open-coding an of_match_device() lookup.
Please split this out into a separate patch.
>
> This also lets the driver drop the of_device.h include.
>
> Assisted-by: OpenCode:BigPickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/input/keyboard/mtk-pmic-keys.c | 53 ++++++++++++--------------
> 1 file changed, 24 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index c78d9f6d97c4..e34856693ee2 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
> @@ -16,7 +16,6 @@
> #include <linux/mfd/mt6397/core.h>
> #include <linux/mfd/mt6397/registers.h>
> #include <linux/module.h>
> -#include <linux/of_device.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> @@ -147,6 +146,7 @@ struct mtk_pmic_keys {
> struct input_dev *input_dev;
> struct device *dev;
> struct regmap *regmap;
> + unsigned int nkeys;
> struct mtk_pmic_keys_info keys[MTK_PMIC_MAX_KEY_COUNT];
> };
>
> @@ -267,7 +267,7 @@ static int mtk_pmic_keys_suspend(struct device *dev)
> struct mtk_pmic_keys *keys = dev_get_drvdata(dev);
> int index;
>
> - for (index = 0; index < MTK_PMIC_MAX_KEY_COUNT; index++) {
> + for (index = 0; index < keys->nkeys; index++) {
> if (keys->keys[index].wakeup) {
> enable_irq_wake(keys->keys[index].irq);
> if (keys->keys[index].irq_r > 0)
> @@ -283,7 +283,7 @@ static int mtk_pmic_keys_resume(struct device *dev)
> struct mtk_pmic_keys *keys = dev_get_drvdata(dev);
> int index;
>
> - for (index = 0; index < MTK_PMIC_MAX_KEY_COUNT; index++) {
> + for (index = 0; index < keys->nkeys; index++) {
> if (keys->keys[index].wakeup) {
> disable_irq_wake(keys->keys[index].irq);
> if (keys->keys[index].irq_r > 0)
> @@ -325,24 +325,23 @@ MODULE_DEVICE_TABLE(of, of_mtk_pmic_keys_match_tbl);
> static int mtk_pmic_keys_probe(struct platform_device *pdev)
> {
> int error, index = 0;
> - unsigned int keycount;
> struct mt6397_chip *pmic_chip = dev_get_drvdata(pdev->dev.parent);
> struct device_node *node = pdev->dev.of_node;
> static const char *const irqnames[] = { "powerkey", "homekey" };
> static const char *const irqnames_r[] = { "powerkey_r", "homekey_r" };
> struct mtk_pmic_keys *keys;
> const struct mtk_pmic_regs *mtk_pmic_regs;
> + struct mtk_pmic_keys_info *key;
> struct input_dev *input_dev;
> - const struct of_device_id *of_id =
> - of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
>
> keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
> if (!keys)
> return -ENOMEM;
> -
> keys->dev = &pdev->dev;
> keys->regmap = pmic_chip->regmap;
> - mtk_pmic_regs = of_id->data;
> + mtk_pmic_regs = of_device_get_match_data(&pdev->dev);
> + if (!mtk_pmic_regs)
> + return -EINVAL;
>
> keys->input_dev = input_dev = devm_input_allocate_device(keys->dev);
> if (!input_dev) {
> @@ -356,31 +355,26 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
> input_dev->id.product = 0x0001;
> input_dev->id.version = 0x0001;
>
> - keycount = of_get_available_child_count(node);
> - if (keycount > MTK_PMIC_MAX_KEY_COUNT ||
> - keycount > ARRAY_SIZE(irqnames)) {
> - dev_err(keys->dev, "too many keys defined (%d)\n", keycount);
> - return -EINVAL;
> - }
> + for_each_available_child_of_node_scoped(node, child) {
Let's keep using for_each_child_of_node_scoped() and check
of_device_is_available() inside the loop. This will allow marking a key
as disabled without shifting it's meaning (power key vs home key).
In the rest of the driver we should be able to determine if key is set
up checking for key->irq > 0.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Dev Jain @ 2026-06-24 4:14 UTC (permalink / raw)
To: Catalin Marinas
Cc: Harry Yoo, ryabinin.a.a, akpm, corbet, glider, andreyknvl,
dvyukov, vincenzo.frascino, kasan-dev, linux-mm, linux-kernel,
skhan, workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajq-Ukmd9NBruhr5@arm.com>
On 23/06/26 10:41 pm, Catalin Marinas wrote:
> On Tue, Jun 23, 2026 at 10:32:16AM +0530, Dev Jain wrote:
>> On 22/06/26 10:43 pm, Catalin Marinas wrote:
>>> On Mon, Jun 22, 2026 at 09:42:10PM +0900, Harry Yoo wrote:
>>>> On 6/19/26 10:19 PM, Catalin Marinas wrote:
>>>>> On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
>>>>>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>>>>>> Now, when a memory object will be freed, it will retain the random tag it
>>>>>>> had at allocation time. This compromises on catching UAF bugs, till the
>>>>>>> time the object is not reallocated, at which point it will have a new
>>>>>>> random tag.
>>>>>>>
>>>>>>> Hence, not catching "use-after-free-before-reallocation" and not catching
>>>>>>> "double-free" will be the compromise for reduced KASAN overhead.
>>>>>>
>>>>>> I doubt users who care about security enough to enable HW_TAGS KASAN
>>>>>> are willing to compromise on security just to save a few instructions
>>>>>> to store tags in the free path.
>>>>>>
>>>>>> To me, it looks like too much of a compromise on security for little
>>>>>> performance gain.
>>>>>
>>>>> I don't think there's much compromise on security for use-after-free.
>>>>
>>>> I think it depends... OH, WAIT! I see what you mean.
>>>>
>>>> You mean use-after-free before reallocation does not lead to much
>>>> compromise on security because objects are initialized after allocation?
>>>>
>>>> You're probably right.
>>>>
>>>> Hmm, but stores to e.g.) free pointer, fields initialized by
>>>> constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
>>>> will be undiscovered if they happen before reallocation.
>>>
>>> Even with SLAB_TYPESAFE_BY_RCU, the object isn't tagged on free either
>>> (or realloc, only if the actual slab page ends up freed). But we don't
>>> get type confusion for such slab.
>>>
>>> However, without tagging on free, one could argue that it reduces
>>> security for cases where the page is re-allocated as untagged - e.g. all
>>> user pages mapped without PROT_MTE. Currently we have a deterministic
>>> tag check fault if the page is coloured as KASAN_TAG_INVALID. I think
>>
>> So you are saying that a stale kernel pointer can continue to use the
>> reallocated page, because for non-PROT_MTE case the page does not get
>> a new tag. Makes sense.
>
> Yes.
>
>>> for this patch, it might be better to only do such skip on free in
>>> kasan_poison_slab() rather than kasan_poison(). Freed pages would then
>>> be tagged.
>>
>> I think you mean to say, "skip tag on free when freeing pages into buddy"?
>
> No, I meant always poison via kasan_poison_pages(), as we currently do
> with KASAN_PAGE_FREE being set.
>
>> So that would mean, kasan_poison() will do the poisoning also in the
>> case of value == KASAN_PAGE_FREE.
Yeah sorry I wrote two contradictory things above, that's what I meant too.
>>
>>> An alternative would be tagging on free only with a new tag and skipping
>>> it on re-alloc. But we'd need to track when it's a completely new
>>> allocation or a reused object (I haven't looked I'm pretty sure it's
>>> doable).
>>
>> That was our original approach, and IIRC we had concluded there was no
>> security compromise. However it is difficult to implement - it has cases
>> like, what happens when two differently tagged pages are coalesced by
>> buddy and someone gets that large page as an allocation.
>
> Yeah, it's fairly complex.
>
> I think the more problematic case is when we can't detect
> use-after-reallocation and this happens when a page is reused untagged
> (probabilistically, also when the page is reused with the old tag). As
> an optimisation, it might be sufficient to skip poisoning when freeing
> an object into the slab but keep the poisoning when freeing a slab page
> into the buddy allocator. That's where the page may end up in a place
> untagged.
>
> Also for your optimisation to only tag on reallocation, do you have any
> code to read the current tag and avoid reusing it? That's useful for
> kmalloc caches or other merged kmem caches where we can have type
> confusion.
I don't have it, but should be fairly simple I guess. I just wanted to
keep it simple for now.
Anyhow someone needs to first test the current patchset to get some
numbers, we would be wasting time on this if no one gets an improvement.
>
^ permalink raw reply
* Re: [RFC PATCH 1/6] media: mc: Implement shared media graph
From: Paul Elder @ 2026-06-24 4:47 UTC (permalink / raw)
To: laurent.pinchart
Cc: michael.riesch, xuhf, stefan.klug, kieran.bingham, dan.scally,
jacopo.mondi, linux-media, linux-arm-kernel, linux-rockchip,
linux-kernel, hverkuil+cisco, nicolas.dufresne, ribalda,
sakari.ailus
In-Reply-To: <20260619052637.1110672-2-paul.elder@ideasonboard.com>
Hi me,
You have a typo...
Quoting Paul Elder (2026-06-19 14:26:28)
> Currently, a media graph contains a main device whose driver is
> responsible for creating the media device. We have however recently run
> into devices that have multiple devices that can quality as a main
> device. Examples are the RK3588 which has a VICAP and two ISP
> instances, and another example is the i.MX8MP which has an ISI and two
> ISP instances. As there is currently no way to reconcile who the main
> device is in the media device, these setups simple cannot be used
> simultaneously.
>
> This patch extends the media controller API with a "shared media graph"
> framework. This allows drivers to share a media device, thus enabling
> the setups mentioned above. Instead of owning and creating a media
> device, drivers can join-or-create a shared media device via the shared
> media graph API. The matching is done automatically based on the
> detected endpoints in the device tree.
>
> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> ---
> drivers/media/mc/Makefile | 2 +-
> drivers/media/mc/mc-shared-graph.c | 335 +++++++++++++++++++++++++++++
> include/media/mc-shared-graph.h | 92 ++++++++
> 3 files changed, 428 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/mc/mc-shared-graph.c
> create mode 100644 include/media/mc-shared-graph.h
>
> diff --git a/drivers/media/mc/Makefile b/drivers/media/mc/Makefile
> index 2b7af42ba59c..1d502fdc52ad 100644
> --- a/drivers/media/mc/Makefile
> +++ b/drivers/media/mc/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> mc-objs := mc-device.o mc-devnode.o mc-entity.o \
> - mc-request.o
> + mc-request.o mc-shared-graph.o
>
> ifneq ($(CONFIG_USB),)
> mc-objs += mc-dev-allocator.o
> diff --git a/drivers/media/mc/mc-shared-graph.c b/drivers/media/mc/mc-shared-graph.c
> new file mode 100644
> index 000000000000..c4067e5b861d
> --- /dev/null
> +++ b/drivers/media/mc/mc-shared-graph.c
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * mc-shared-graph.c - Media Controller Shared Graph API
> + *
> + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> + */
> +
> +/*
> + * This file adds the Media Controller Shared Graph API. This allows drivers
> + * to create shared media graphs or join existing media graphs from other
> + * drivers, so that they can all be in the same media graph. This allows us to
> + * have more complex media graphs chaining more complex hardware together,
> + * instead of simple async subdevs.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/fwnode.h>
> +#include <linux/kref.h>
> +#include <linux/property.h>
> +
> +#include <media/media-device.h>
> +
> +#include <media/mc-shared-graph.h>
> +
> +static LIST_HEAD(media_device_shared_list);
> +static DEFINE_MUTEX(media_device_shared_lock);
> +
> +struct media_device_shared_member {
> + struct device *dev;
> + struct fwnode_handle *fwnode;
> + struct list_head list;
> +};
> +
> +struct media_device_shared_link {
> + struct media_entity *source;
> + u16 source_pad;
> + struct media_entity *sink;
> + u16 sink_pad;
> + u32 flags;
> + struct list_head list;
> +};
> +
> +// TODO figure out locking for when multiple drivers touch the media graph;
> +// maybe macros for shared versions?
> +struct media_device_shared {
> + struct media_device mdev;
> + struct list_head members;
> + struct list_head links;
> +
> + struct list_head list;
> + struct kref refcount;
> +
> + struct device *removed_device;
> +};
> +
> +static inline struct media_device_shared *
> +to_media_device_shared(struct media_device *mdev)
> +{
> + return container_of(mdev, struct media_device_shared, mdev);
> +}
> +
> +static void media_device_shared_release(struct kref *kref)
> +{
> + struct media_device_shared *mds =
> + container_of(kref, struct media_device_shared, refcount);
> +
> + dev_dbg(mds->removed_device, "%s: releasing Media Device\n", __func__);
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + media_device_unregister(&mds->mdev);
> + media_device_cleanup(&mds->mdev);
> +
> + list_del(&mds->list);
> + mutex_unlock(&media_device_shared_lock);
> +
> + kfree(mds);
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static bool __media_device_shared_find_match(struct media_device_shared *mds,
> + struct fwnode_handle *fwnode)
> +{
> + struct media_device_shared_member *member;
> + struct fwnode_handle *ep;
> + struct fwnode_handle *remote_ep;
> + bool match = false;
> +
> + // TODO: parse the device tree endpoints graph instead of finding just the
> + // first-level neighbours
> + fwnode_graph_for_each_endpoint(fwnode, ep) {
> + list_for_each_entry(member, &mds->members, list) {
> + remote_ep = fwnode_graph_get_remote_port_parent(ep);
> + match = (member->fwnode == remote_ep);
> + fwnode_handle_put(remote_ep);
> +
> + if (!match)
> + continue;
> +
> + goto match_complete;
> + }
> + }
> +
> +match_complete:
> + fwnode_handle_put(ep);
> + return match;
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static struct media_device *__media_device_shared_get(struct device *dev)
> +{
> + struct media_device_shared *mds;
> + struct media_device_shared_member *member;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + bool ret;
> +
> + dev_dbg(dev, "%s: searching for media device for %pfwf", __func__, fwnode);
> +
> + list_for_each_entry(mds, &media_device_shared_list, list) {
> + ret = __media_device_shared_find_match(mds, fwnode);
> + if (ret)
> + break;
> + }
> +
> + if (!ret)
> + return NULL;
> +
> + member = kzalloc_obj(*member);
> + if (!member)
> + return NULL;
> +
> + member->dev = dev;
> + member->fwnode = fwnode;
> + list_add_tail(&member->list, &mds->members);
> + kref_get(&mds->refcount);
> +
> + dev_dbg(dev, "%s: %pfwf joined media device of %pfwf",
> + __func__, fwnode,
> + list_first_entry(&mds->members, struct media_device_shared_member, list)->fwnode);
> +
> + return &mds->mdev;
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static struct media_device *__media_device_shared_create(struct device *dev)
> +{
> + struct media_device_shared *mds;
> + struct media_device_shared_member *member;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + int ret;
> +
> + mds = kzalloc_obj(*mds);
> + if (!mds)
> + return NULL;
> +
> + member = kzalloc_obj(*member);
> + if (!member)
> + goto err_free_mds;
> +
> + media_device_init(&mds->mdev);
> +
> + ret = media_device_register(&mds->mdev);
> + if (ret)
> + goto err_free_member;
> +
> + INIT_LIST_HEAD(&mds->members);
> + member->dev = dev;
> + member->fwnode = fwnode;
> + list_add_tail(&member->list, &mds->members);
> +
> + INIT_LIST_HEAD(&mds->links);
> +
> + kref_init(&mds->refcount);
> + list_add_tail(&mds->list, &media_device_shared_list);
> +
> + // TODO figure out how to reconcile this with multiple members
> + mds->mdev.dev = dev;
> +
> + devv_dbg(dev, "%s: Allocated media device with %pfwf at %p\n",
here:
s/devv/dev/
Paul
> + __func__, fwnode, &mds->mdev);
> + return &mds->mdev;
> +
> +err_free_member:
> + kfree(member);
> +err_free_mds:
> + kfree(mds);
> + return NULL;
> +}
> +
> +// TODO figure out how to resolve the identifiers (model, driver name, etc);
> +// atm it's racy and whoever gets it last wins
> +struct media_device *media_device_shared_join(struct device *dev)
> +{
> + struct media_device *mdev;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + mdev = __media_device_shared_get(dev);
> + if (!!mdev) {
> + dev_dbg(dev, "%s: found media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return mdev;
> + }
> +
> + mdev = __media_device_shared_create(dev);
> + if (!mdev) {
> + dev_warn(dev, "%s: failed to create media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + dev_dbg(dev, "%s: created media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return mdev;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join);
> +
> +void media_device_shared_leave(struct media_device *mdev, struct device *dev)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_member *member;
> + struct media_device_shared_member *member_tmp;
> + bool removed = false;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + list_for_each_entry_safe(member, member_tmp, &mds->members, list) {
> + if (member->dev == dev) {
> + list_del(&member->list);
> + kfree(member);
> + removed = true;
> + }
> + }
> +
> + if (!removed)
> + dev_err(dev, "%s: %pfwf trying to leave from graph in which not a member",
> + __func__, dev_fwnode(dev));
> +
> + mds->removed_device = dev;
> + mutex_unlock(&media_device_shared_lock);
> + kref_put(&mds->refcount, media_device_shared_release);
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_leave);
> +
> +int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_link *link;
> + struct media_device_shared_link *link_tmp;
> + int ret = 0;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + /*
> + * TODO Figure out flags. Should we use greatest common denominator? Or
> + * prioritize sink? Or whoever wins the race? For now we just take the flags
> + * from the sink.
> + *
> + * TODO Figure out how to actually do the matching. For now we just match
> + * whoever comes in first. This works with the simple example we're running
> + * with now (rkcif + one rkisp2) but with setups with multiple copies of
> + * hardware this will cause problems, like with rkcif + two rkisp2 and
> + * imx8-isi + two rkisp1.
> + */
> + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> + if (link->sink) {
> + ret = media_create_pad_link(source, source_pad,
> + link->sink, link->sink_pad,
> + link->flags);
> + list_del(&link->list);
> + kfree(link);
> + goto exit_join_link_source;
> + }
> + }
> +
> + link = kzalloc_obj(*link);
> + if (!link) {
> + ret = -ENOMEM;
> + goto exit_join_link_source;
> + }
> +
> + link->source = source;
> + link->source_pad = source_pad;
> + link->flags = flags;
> + list_add_tail(&link->list, &mds->links);
> +
> +exit_join_link_source:
> + mutex_unlock(&media_device_shared_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join_link_source);
> +
> +// TODO deduplicate from above
> +int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_link *link;
> + struct media_device_shared_link *link_tmp;
> + int ret = 0;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> + if (link->source) {
> + ret = media_create_pad_link(link->source, link->source_pad,
> + sink, sink_pad,
> + flags);
> + list_del(&link->list);
> + kfree(link);
> + goto exit_join_link_sink;
> + }
> + }
> +
> + link = kzalloc_obj(*link);
> + if (!link) {
> + ret = -ENOMEM;
> + goto exit_join_link_sink;
> + }
> +
> + link->sink = sink;
> + link->sink_pad = sink_pad;
> + link->flags = flags;
> + list_add_tail(&link->list, &mds->links);
> +
> +exit_join_link_sink:
> + mutex_unlock(&media_device_shared_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join_link_sink);
> diff --git a/include/media/mc-shared-graph.h b/include/media/mc-shared-graph.h
> new file mode 100644
> index 000000000000..487325163f84
> --- /dev/null
> +++ b/include/media/mc-shared-graph.h
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * mc-shared-graph.h - Media Controller Shared Graph API
> + *
> + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> + */
> +
> +/*
> + * This file adds the Media Controller Shared Graph API. This allows drivers
> + * to create shared media graphs or join existing media graphs from other
> + * drivers, so that they can all be in the same media graph. This allows us to
> + * have more complex media graphs chaining more complex hardware together,
> + * instead of simple async subdevs.
> + */
> +
> +#include <linux/types.h>
> +
> +#ifndef _MEDIA_SHARED_GRAPH_H
> +#define _MEDIA_SHARED_GRAPH_H
> +
> +struct device;
> +struct media_device;
> +struct media_entity;
> +
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> +/**
> + * media_device_shared_join() - Join or create a new shared media device
> + *
> + * @dev: struct &device pointer
> + *
> + * This is the entrance function for a device to join or create a new shared
> + * media device. It searches for an existing shared media device based on the
> + * neighbours in the device's device tree ports node. If found, then this
> + * functions returns the existing shared media device and joins it. If one is
> + * not found then one is created and initialized and returned.
> + */
> +struct media_device *media_device_shared_join(struct device *dev);
> +
> +/**
> + * media_device_shared_leave() - Leave the shared media device.
> + *
> + * @mdev: struct &media_device pointer
> + * @dev: struct &device pointer
> + *
> + * This function makes the device leave the shared media device. When all
> + * members have left the media device it will be freed.
> + */
> +void media_device_shared_leave(struct media_device *mdev, struct device *dev);
> +
> +/**
> + * media_device_shared_join_link_source() - Register a link source in the shared media device
> + *
> + * @mdev: The struct &media_device pointer that is part of a shared media device
> + * @dev: struct &device pointer
> + * @source: The link source
> + * @source_pad: The pad
> + * @flags: The flags
> + *
> + * This function registers with the shared media device the source part of a
> + * link. When the shared media device receives the matching sink part of a link
> + * via media_device_shared_join_link_sink() then the link will be fully created.
> + */
> +int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags);
> +
> +/**
> + * media_device_shared_join_link_sink() - Register a link sink in the shared media device
> + *
> + * Same as media_device_shared_join_link_source() but for sink instead of
> + * source.
> + */
> +int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags);
> +#else
> +static inline struct media_device *media_device_shared_join(struct device *dev)
> +{ return NULL; }
> +static inline void media_device_shared_leave(struct media_device *mdev,
> + struct device *dev) { }
> +static inline int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags) { }
> +static inline int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags) { }
> +#endif /* CONFIG_MEDIA_CONTROLLER */
> +#endif /* _MEDIA_DEV_SHARED_GRAPH_H */
> --
> 2.47.2
>
^ permalink raw reply
* Re: [PATCH v4 0/2] Bluetooth: btmtksdio: teardown fixes
From: Sergey Senozhatsky @ 2026-06-24 5:19 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Sean Wang
Cc: Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, Sergey Senozhatsky
In-Reply-To: <20260618031338.1011410-1-senozhatsky@chromium.org>
On (26/06/18 12:13), Sergey Senozhatsky wrote:
> This fixes several teardown issues:
>
> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> __cancel_work_timer+0x3f4/0x460
> cancel_work_sync+0x1c/0x2c
> btmtksdio_flush+0x2c/0x40
> hci_dev_open_sync+0x10c4/0x2190
> [..]
>
> close/flush can deadlock when run concurrently with btmtksdio_txrx_work().
> In addition btmtksdio_txrx_work() re-enables interrupts regardless of
> close/flush being executed on another CPU.
>
> v3 -> v4:
> - fix commit message linter warnings/errors (tabs, subject line over 80
> chars).
>
> Sergey Senozhatsky (2):
> Bluetooth: btmtksdio: test for BUS IO errors in btmtksdio_txrx_work()
> Bluetooth: btmtksdio: call cancel_work_sync() out of host lock scope
Do the patches look good enough to pick up?
^ permalink raw reply
* [PATCH 0/2] Add AST2700 PECI clock support
From: Ryan Chen @ 2026-06-24 5:44 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
Add the PECI clock for the AST2700 SoC1. The PECI clock is a mux
controlled by SCU1_CLK_SEL2 bit 16, selecting between the 25MHz CLKIN
and HPLL/4.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Ryan Chen (2):
dt-bindings: clock: ast2700: add PECI clock
clk: aspeed: add AST2700 PECI clock
drivers/clk/aspeed/clk-ast2700.c | 10 ++++++++++
include/dt-bindings/clock/aspeed,ast2700-scu.h | 2 ++
2 files changed, 12 insertions(+)
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260623-peci_clk-ba87e043ee5f
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply
* [PATCH 2/2] clk: aspeed: add AST2700 PECI clock
From: Ryan Chen @ 2026-06-24 5:45 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260624-peci_clk-v1-0-ee28b92e22e9@aspeedtech.com>
Register the SoC1 PECI clock as a mux selected by SCU1_CLK_SEL2 bit 16,
choosing between the 25MHz CLKIN and HPLL/4. Add the HPLL/4 fixed factor
clock to serve as the second mux parent.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
drivers/clk/aspeed/clk-ast2700.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/aspeed/clk-ast2700.c b/drivers/clk/aspeed/clk-ast2700.c
index 8b7b382f6f3e..5f499ec0e1d1 100644
--- a/drivers/clk/aspeed/clk-ast2700.c
+++ b/drivers/clk/aspeed/clk-ast2700.c
@@ -273,6 +273,13 @@ static const unsigned int sdclk_parent_ids[] = {
static const struct clk_hw *sdclk_parent_hws[ARRAY_SIZE(sdclk_parent_ids)];
+static const unsigned int peciclk_parent_ids[] = {
+ SCU1_CLKIN,
+ SCU1_CLK_HPLL_DIV4
+};
+
+static const struct clk_hw *peciclk_parent_hws[ARRAY_SIZE(peciclk_parent_ids)];
+
#define FIXED_CLK(_id, _name, _rate) \
{ \
.id = _id, \
@@ -458,6 +465,7 @@ static const struct ast2700_clk_info ast2700_scu1_clk_info[] __initconst = {
PLL_CLK(SCU1_CLK_HPLL, CLK_PLL, "soc1-hpll", SCU1_CLKIN, SCU1_HPLL_PARAM),
PLL_CLK(SCU1_CLK_APLL, CLK_PLL, "soc1-apll", SCU1_CLKIN, SCU1_APLL_PARAM),
PLL_CLK(SCU1_CLK_DPLL, CLK_PLL, "soc1-dpll", SCU1_CLKIN, SCU1_DPLL_PARAM),
+ FIXED_FACTOR_CLK(SCU1_CLK_HPLL_DIV4, "soc1-hpll_div4", SCU1_CLK_HPLL, 1, 4),
FIXED_FACTOR_CLK(SCU1_CLK_APLL_DIV2, "soc1-apll_div2", SCU1_CLK_APLL, 1, 2),
FIXED_FACTOR_CLK(SCU1_CLK_APLL_DIV4, "soc1-apll_div4", SCU1_CLK_APLL, 1, 4),
FIXED_FACTOR_CLK(SCU1_CLK_CAN, "canclk", SCU1_CLK_APLL, 1, 10),
@@ -481,6 +489,8 @@ static const struct ast2700_clk_info ast2700_scu1_clk_info[] __initconst = {
uxclk_parent_hws, SCU1_CLK_SEL2, 0, 2),
MUX_CLK(SCU1_CLK_HUXCLK, "huxclk", uxclk_parent_ids, ARRAY_SIZE(uxclk_parent_ids),
uxclk_parent_hws, SCU1_CLK_SEL2, 3, 2),
+ MUX_CLK(SCU1_CLK_PECI, "peciclk", peciclk_parent_ids, ARRAY_SIZE(peciclk_parent_ids),
+ peciclk_parent_hws, SCU1_CLK_SEL2, 16, 1),
DIVIDER_CLK(SCU1_CLK_SDCLK, "sdclk", SCU1_CLK_SDMUX,
SCU1_CLK_SEL1, 14, 3, ast2700_clk_div_table),
PLL_CLK(SCU1_CLK_UARTX, CLK_UART_PLL, "uartxclk", SCU1_CLK_UXCLK, SCU1_UXCLK_CTRL),
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: clock: ast2700: add PECI clock
From: Ryan Chen @ 2026-06-24 5:44 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260624-peci_clk-v1-0-ee28b92e22e9@aspeedtech.com>
Add SCU1_CLK_PECI for the SoC1 PECI controller clock source, and
SCU1_CLK_HPLL_DIV4 which serves as one of the PECI clock mux parents.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
include/dt-bindings/clock/aspeed,ast2700-scu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/aspeed,ast2700-scu.h b/include/dt-bindings/clock/aspeed,ast2700-scu.h
index bacf712e8e04..138f78ce5f07 100644
--- a/include/dt-bindings/clock/aspeed,ast2700-scu.h
+++ b/include/dt-bindings/clock/aspeed,ast2700-scu.h
@@ -163,5 +163,7 @@
#define SCU1_CLK_GATE_PORTDUSB2CLK 85
#define SCU1_CLK_GATE_LTPI1TXCLK 86
#define SCU1_CLK_I3C 87
+#define SCU1_CLK_HPLL_DIV4 88
+#define SCU1_CLK_PECI 89
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH 1/1] arm: backtrace-clang: fix wrong sp usage for unwinding
From: Maninder Singh @ 2026-06-24 5:49 UTC (permalink / raw)
To: linux, nathan, nick.desaulniers+lkml, morbo, justinstitt
Cc: onkarnath.1, linux-arm-kernel, linux-kernel, llvm, r.thapliyal,
Maninder Singh
In-Reply-To: <CGME20260624054927epcas5p3f8e7be966570a89e722cc718475320fa@epcas5p3.samsung.com>
show_stack() can be called for any task, however c_backtrace always unwinds
frames based on the "sp" register. This results in printing the backtrace of
the current task instead of the target task.
Try with normal TC:
==================
for_each_process(p) {
sched_show_task(p);
}
[7.433271] task:kthreadd state:S stack:0 pid:2 tgid:2 ppid:0 task_flags:0x208040 flags:0x00000000
[7.433633] Call trace:
[7.433640] [<80113418>] (dump_backtrace) from [<80113510>] (show_stack+0x14/0x18)
..
[7.433676] [<8016749c>] (sched_show_task) from [<803cb324>] (meminfo_proc_show+0x6c/0x930)
[7.434019] r5:8158e300 r4:8b4882d0
[7.434024] [<803cb324>] (meminfo_proc_show) from [<80365788>] (seq_read_iter+0x148/0x4bc)
[7.434045] [<80365788>] (seq_read_iter) from [<803c044c>] (proc_reg_read_iter+0xb8/0xc4)
[7.434060] [<803c044c>] (proc_reg_read_iter) from [<80377104>] (copy_splice_read+0x228/0x308)
It should unwind frame based on passed "fp".
(CONFIG_UNWINDER_FRAME_POINTER=y)
With fix:
=========
[13.933732] task:kthreadd state:S stack:0 pid:2 tgid:2 ppid:0 task_flags:0x208040 flags:0x00000000
[13.934165] Call trace:
[13.934604] [<80afa1a8>] (schedule) from [<8015426c>] (kthreadd+0x124/0x208)
[13.934654] r10:8100bbf0 r4:8116f440
[13.934664] [<8015426c>] (kthreadd) from [<8010010c>] (ret_from_fork+0x14/0x28)
[13.934691] Exception stack(0xf081df9c to 0xf081dfe4)
Additionally, the extra manipulation of "sp" register appears unnecessary in the "current"
task also since the "fp" register is already provided.
Signed-off-by: Onkarnath <onkarnath.1@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
arch/arm/lib/backtrace-clang.S | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/lib/backtrace-clang.S b/arch/arm/lib/backtrace-clang.S
index 290c52a60fc6..993410a6afd1 100644
--- a/arch/arm/lib/backtrace-clang.S
+++ b/arch/arm/lib/backtrace-clang.S
@@ -105,10 +105,6 @@ ENDPROC(c_backtrace)
moveq mask, #0xfc000003
movne mask, #0 @ mask for 32-bit
-/*
- * Switches the current frame to be the frame for dump_stack.
- */
- add frame, sp, #24 @ switch to false frame
for_each_frame: tst frame, mask @ Check for address exceptions
bne no_frame
--
2.34.1
^ permalink raw reply related
* [PATCH] can: rockchip_canfd: Propagate reset failures on start
From: Pengpeng Hou @ 2026-06-24 5:50 UTC (permalink / raw)
To: Marc Kleine-Budde, kernel, Vincent Mailhol, Heiko Stuebner,
Philipp Zabel
Cc: linux-can, linux-arm-kernel, linux-rockchip, linux-kernel,
Pengpeng Hou
The Rockchip CAN-FD driver requires a reset controller, but
rkcanfd_chip_set_reset_mode() ignores reset assert/deassert failures.
rkcanfd_open() and CAN_MODE_START can then report success after the
controller failed to enter a known reset state.
Return reset errors from the reset/start helpers and propagate them
before enabling RX offload, requesting the IRQ, or starting the netdev
queue.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
.../net/can/rockchip/rockchip_canfd-core.c | 40 +++++++++++++++----
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e4ed..89bc402b76e8 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -102,13 +102,23 @@ static const struct can_bittiming_const rkcanfd_data_bittiming_const = {
.brp_inc = 2, /* value from data sheet x2 */
};
-static void rkcanfd_chip_set_reset_mode(const struct rkcanfd_priv *priv)
+static int rkcanfd_chip_set_reset_mode(const struct rkcanfd_priv *priv)
{
- reset_control_assert(priv->reset);
+ int err;
+
+ err = reset_control_assert(priv->reset);
+ if (err)
+ return err;
+
udelay(2);
- reset_control_deassert(priv->reset);
+
+ err = reset_control_deassert(priv->reset);
+ if (err)
+ return err;
rkcanfd_write(priv, RKCANFD_REG_MODE, 0x0);
+
+ return 0;
}
static void rkcanfd_chip_set_work_mode(const struct rkcanfd_priv *priv)
@@ -246,11 +256,14 @@ static void rkcanfd_chip_fifo_setup(struct rkcanfd_priv *priv)
netdev_reset_queue(priv->ndev);
}
-static void rkcanfd_chip_start(struct rkcanfd_priv *priv)
+static int rkcanfd_chip_start(struct rkcanfd_priv *priv)
{
u32 reg;
+ int err;
- rkcanfd_chip_set_reset_mode(priv);
+ err = rkcanfd_chip_set_reset_mode(priv);
+ if (err)
+ return err;
/* Receiving Filter: accept all */
rkcanfd_write(priv, RKCANFD_REG_IDCODE, 0x0);
@@ -309,13 +322,16 @@ static void rkcanfd_chip_start(struct rkcanfd_priv *priv)
netdev_dbg(priv->ndev, "%s: reg_mode=0x%08x\n", __func__,
rkcanfd_read(priv, RKCANFD_REG_MODE));
+
+ return 0;
}
static void __rkcanfd_chip_stop(struct rkcanfd_priv *priv, const enum can_state state)
{
priv->can.state = state;
- rkcanfd_chip_set_reset_mode(priv);
+ if (rkcanfd_chip_set_reset_mode(priv))
+ netdev_err(priv->ndev, "Failed to reset CAN-FD controller\n");
rkcanfd_chip_interrupts_disable(priv);
}
@@ -339,10 +355,14 @@ static int rkcanfd_set_mode(struct net_device *ndev,
enum can_mode mode)
{
struct rkcanfd_priv *priv = netdev_priv(ndev);
+ int err;
switch (mode) {
case CAN_MODE_START:
- rkcanfd_chip_start(priv);
+ err = rkcanfd_chip_start(priv);
+ if (err)
+ return err;
+
rkcanfd_chip_interrupts_enable(priv);
netif_wake_queue(ndev);
break;
@@ -719,7 +739,10 @@ static int rkcanfd_open(struct net_device *ndev)
if (err)
goto out_close_candev;
- rkcanfd_chip_start(priv);
+ err = rkcanfd_chip_start(priv);
+ if (err)
+ goto out_runtime_put;
+
can_rx_offload_enable(&priv->offload);
err = request_irq(ndev->irq, rkcanfd_irq, IRQF_SHARED, ndev->name, priv);
@@ -734,6 +757,7 @@ static int rkcanfd_open(struct net_device *ndev)
out_rkcanfd_chip_stop:
rkcanfd_chip_stop_sync(priv, CAN_STATE_STOPPED);
+out_runtime_put:
pm_runtime_put(ndev->dev.parent);
out_close_candev:
close_candev(ndev);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] drm/sun4i: mixer: Check clock enable failures
From: Pengpeng Hou @ 2026-06-24 5:51 UTC (permalink / raw)
To: Chen-Yu Tsai, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Samuel Holland,
dri-devel
Cc: linux-arm-kernel, linux-sunxi, linux-kernel, Pengpeng Hou
sun8i_mixer_bind() acquires the required bus and module clocks, but
ignores clk_prepare_enable() failures before adding the mixer engine to
the DRM pipeline.
Check both clock enable operations and use the existing unwind labels
when a required clock cannot be enabled.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index ce9c155bfad7..c6546f933b13 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -616,7 +616,11 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master,
ret = PTR_ERR(mixer->bus_clk);
goto err_assert_reset;
}
- clk_prepare_enable(mixer->bus_clk);
+ ret = clk_prepare_enable(mixer->bus_clk);
+ if (ret) {
+ dev_err(dev, "Couldn't enable the mixer bus clock\n");
+ goto err_assert_reset;
+ }
mixer->mod_clk = devm_clk_get(dev, "mod");
if (IS_ERR(mixer->mod_clk)) {
@@ -633,7 +637,11 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master,
if (mixer->cfg->mod_rate)
clk_set_rate(mixer->mod_clk, mixer->cfg->mod_rate);
- clk_prepare_enable(mixer->mod_clk);
+ ret = clk_prepare_enable(mixer->mod_clk);
+ if (ret) {
+ dev_err(dev, "Couldn't enable the mixer module clock\n");
+ goto err_disable_bus_clk;
+ }
list_add_tail(&mixer->engine.list, &drv->engine_list);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] rtc: zynqmp: Return optional clock lookup errors
From: Pengpeng Hou @ 2026-06-24 5:55 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Pengpeng Hou
devm_clk_get_optional() returns NULL when the optional clock is absent,
but returns an ERR_PTR when the clock provider lookup fails. Probe
currently keeps the ERR_PTR and then passes it to clk_get_rate().
Return the lookup error instead. A truly absent optional clock still
reaches the existing calibration fallback through clk_get_rate(NULL).
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/rtc/rtc-zynqmp.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
index 2ae54804b87a..5bcb7536e973 100644
--- a/drivers/rtc/rtc-zynqmp.c
+++ b/drivers/rtc/rtc-zynqmp.c
@@ -334,10 +334,9 @@ static int xlnx_rtc_probe(struct platform_device *pdev)
/* Getting the rtc info */
xrtcdev->rtc_clk = devm_clk_get_optional(&pdev->dev, "rtc");
- if (IS_ERR(xrtcdev->rtc_clk)) {
- if (PTR_ERR(xrtcdev->rtc_clk) != -EPROBE_DEFER)
- dev_warn(&pdev->dev, "Device clock not found.\n");
- }
+ if (IS_ERR(xrtcdev->rtc_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(xrtcdev->rtc_clk),
+ "Failed to get rtc clock\n");
xrtcdev->freq = clk_get_rate(xrtcdev->rtc_clk);
if (!xrtcdev->freq) {
ret = of_property_read_u32(pdev->dev.of_node, "calibration",
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] usb: dwc3: st: Propagate reset deassert failures
From: Pengpeng Hou @ 2026-06-24 5:57 UTC (permalink / raw)
To: Patrice Chotard, Thinh Nguyen, Greg Kroah-Hartman, Philipp Zabel
Cc: linux-arm-kernel, linux-usb, linux-kernel, Pengpeng Hou
The ST DWC3 glue driver treats the powerdown and softreset reset
controls as required resources, but ignores reset_control_deassert()
failures before populating the child DWC3 device. Resume ignores the
same failures before returning success.
Check the deassert operations and unwind the already deasserted
powerdown reset if softreset deassertion fails.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/usb/dwc3/dwc3-st.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index 5d513decaacd..bbabfd933798 100644
--- a/drivers/usb/dwc3/dwc3-st.c
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -242,7 +242,9 @@ static int st_dwc3_probe(struct platform_device *pdev)
"could not get power controller\n");
/* Manage PowerDown */
- reset_control_deassert(dwc3_data->rstc_pwrdn);
+ ret = reset_control_deassert(dwc3_data->rstc_pwrdn);
+ if (ret)
+ return ret;
dwc3_data->rstc_rst =
devm_reset_control_get_shared(dev, "softreset");
@@ -253,7 +255,9 @@ static int st_dwc3_probe(struct platform_device *pdev)
}
/* Manage SoftReset */
- reset_control_deassert(dwc3_data->rstc_rst);
+ ret = reset_control_deassert(dwc3_data->rstc_rst);
+ if (ret)
+ goto undo_powerdown;
/* Allocate and initialize the core */
ret = of_platform_populate(node, NULL, NULL, dev);
@@ -328,8 +332,15 @@ static int st_dwc3_resume(struct device *dev)
pinctrl_pm_select_default_state(dev);
- reset_control_deassert(dwc3_data->rstc_pwrdn);
- reset_control_deassert(dwc3_data->rstc_rst);
+ ret = reset_control_deassert(dwc3_data->rstc_pwrdn);
+ if (ret)
+ return ret;
+
+ ret = reset_control_deassert(dwc3_data->rstc_rst);
+ if (ret) {
+ reset_control_assert(dwc3_data->rstc_pwrdn);
+ return ret;
+ }
ret = st_dwc3_drd_init(dwc3_data);
if (ret) {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Michal Simek @ 2026-06-24 6:12 UTC (permalink / raw)
To: tanmay.shah, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
In-Reply-To: <a9baf2c9-d4d9-4152-9188-c33fce2daf15@amd.com>
On 6/23/26 00:29, Shah, Tanmay wrote:
> Hello,
>
>
> On 6/22/2026 7:25 AM, Michal Simek wrote:
>>
>>
>> On 6/19/26 18:38, Tanmay Shah wrote:
>>> Current _start and _stop ops are implemented using various APIs from the
>>> platform management firmware driver. Instead provide respective RPU
>>> start and stop API in the firmware driver and move the logic to interact
>>> with the PM firmware in the firmware driver. The remoteproc driver
>>> doesn't
>>> need to know actual logic, but only the final result i.e. RPU start/stop
>>> was success or not. This refactor keeps the remoteproc driver simple and
>>> moves firmware interaction logic to the firmware driver.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>> drivers/firmware/xilinx/zynqmp.c | 93 +++++++++++++++++++++++++
>>> drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
>>> include/linux/firmware/xlnx-zynqmp.h | 12 ++++
>>> 3 files changed, 110 insertions(+), 63 deletions(-)
>>>
>>> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/
>>> xilinx/zynqmp.c
>>> index af838b2dc327..f9a3a95b0638 100644
>>> --- a/drivers/firmware/xilinx/zynqmp.c
>>> +++ b/drivers/firmware/xilinx/zynqmp.c
>>> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
>>> }
>>> EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>>> +/**
>>> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on
>>> SoC
>>> + *
>>> + * @node: power-domains id of the core
>>> + * @bootaddr: Boot address of elf
>>> + *
>>> + * Return: status, either success or error+reason
>>> + */
>>> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
>>> +{
>>> + enum rpu_boot_mem bootmem;
>>> + int ret;
>>> +
>>> + /*
>>> + * The exception vector pointers (EVP) refer to the base-address of
>>> + * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
>>> + * starts at the base-address and subsequent vectors are on 4-byte
>>> + * boundaries.
>>> + *
>>> + * Exception vectors can start either from 0x0000_0000 (LOVEC) or
>>> + * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip
>>> Memory)
>>
>> here
>>
>>> + *
>>> + * Usually firmware will put Exception vectors at LOVEC.
>>> + *
>>> + * It is not recommend that you change the exception vector.
>>> + * Changing the EVP to HIVEC will result in increased interrupt
>>> latency
>>> + * and jitter. Also, if the OCM is secured and the Cortex-R5F
>>> processor
>>> + * is non-secured, then the Cortex-R5F processor cannot access the
>>> + * HIVEC exception vectors in the OCM.
>>> + */
>>> + bootmem = (bootaddr >= 0xFFFC0000) ?
>>
>> and here you have different values without any explanation why.
>>
>
> The value in the comment is correct, but the check is done for all of
> OCM address range. This is just refactoring of the interfaces and not
> the actual logic. There is a separate patch which actually refactors the
> logic, I will send it later. I would like to keep this as it is because
> this was originally there, and the intent of the commit is not to modify it.
ok.
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 0/3] KVM: arm64: nv: Shadow ptdump fixes
From: Itaru Kitayama @ 2026-06-24 6:02 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260623142443.648972-1-weilin.chang@arm.com>
Hi Wei-Lin,
On Tue, Jun 23, 2026 at 03:24:40PM +0100, Wei-Lin Chang wrote:
> Hi,
>
> This series fixes two bugs regarding the shadow ptdump debugfs files.
> It is based on kvmarm/fixes + [1] ("KVM: arm64: Reassign nested_mmus
> array behind mmu_lock").
>
> The first is a UAF. A nested mmu can still be accessed when the debugfs
> file is being closed, after the nested mmus are freed. I can observe
> this by turning on CONFIG_KASAN and closing the file after the VM is
> destroyed. To fix this, mmu access is avoided in the .release()
> callback.
>
> The second is sleeping in atomic context, found by Itaru [2] (thanks).
> Originally the code creates a debugfs file whenever a context gets bound
> to an s2 mmu instance, and deletes it when it gets unbound. Problem is
> the bind/unbind is done with the mmu_lock held, and debugfs file
> creation and deletion can sleep. This is observable by using
> CONFIG_DEBUG_ATOMIC_SLEEP. The new approach is just have one debugfs
> file for each s2 mmu instance, and show their state + information when
> requested, which can be invalid, or VTCR + VTTBR + whether s2 enabled +
> ptdump.
>
> The fixes are tested with CONFIG_PROVE_LOCKING,
> CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
>
> Thanks!
> Wei-Lin Chang
>
> [1]: https://lore.kernel.org/kvmarm/aiKIVVeIr1aAB1yp@v4bel/
> [2]: https://lore.kernel.org/kvmarm/aiuF0KSvvv-ZozI1@sm-arm-grace07/
>
> Wei-Lin Chang (3):
> KVM: arm64: nv: Print nested mmu info in kvm_ptdump_guest_show()
> KVM: arm64: ptdump: Store both mmu and kvm pointers in
> kvm_ptdump_guest_state
> KVM: arm64: nv: Move to per nested mmu ptdump files
>
> arch/arm64/kvm/nested.c | 16 +++++++++++-----
> arch/arm64/kvm/ptdump.c | 29 +++++++++++++++++++----------
> 2 files changed, 30 insertions(+), 15 deletions(-)
>
> --
> 2.43.0
At end of the execution of the shadow stage 2 selftest I see:
[ 569.228448] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[ 569.228712] Mem abort info:
[ 569.229091] ESR = 0x0000000096000046
[ 569.229165] EC = 0x25: DABT (current EL), IL = 32 bits
[ 569.229213] SET = 0, FnV = 0
[ 569.229244] EA = 0, S1PTW = 0
[ 569.229276] FSC = 0x06: level 2 translation fault
[ 569.229312] Data abort info:
[ 569.229341] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
[ 569.229369] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 569.229397] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 569.229458] user pgtable: 4k pages, 48-bit VAs, pgdp=000000006dce3000
[ 569.229545] [0000000000000098] pgd=0800000048b63403, p4d=0800000048b63403, pud=0800000048b7f403, pmd=0000000000000
** replaying previous printk message **
[ 569.229545] [0000000000000098] pgd=0800000048b63403, p4d=0800000048b63403, pud=0800000048b7f403, pmd=0000000000000000
[ 569.236428] Internal error: Oops: 0000000096000046 [#1] SMP
[ 569.237974] Modules linked in:
[ 569.238644] CPU: 1 UID: 0 PID: 824 Comm: shadow_stage2 Not tainted 7.1.0-rc4+ #59 PREEMPT(full)
[ 569.239139] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2ubuntu0.7 11/27/2025
[ 569.239632] pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 569.240004] pc : down_write+0x50/0xe8
[ 569.240450] lr : down_write+0x34/0xe8
[ 569.240696] sp : ffff80008252ba20
[ 569.240965] x29: ffff80008252ba20 x28: 0000000000000000 x27: 0000000040000200
[ 569.241346] x26: 0000000000000200 x25: ffffd1bf542891a0 x24: 0000000000000001
[ 569.241625] x23: 0000000000000098 x22: ffff000000637480 x21: ffffd1bf57abc518
[ 569.241985] x20: 0000000000000000 x19: 0000000000000098 x18: ffff80008253d090
[ 569.242261] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 569.242568] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 569.242904] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd1bf5532388c
[ 569.243335] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[ 569.243638] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 569.244056] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000
[ 569.244507] Call trace:
[ 569.244778] down_write+0x50/0xe8 (P)
[ 569.245094] __simple_recursive_removal+0x68/0x230
[ 569.245322] simple_recursive_removal+0x20/0x50
[ 569.245498] debugfs_remove+0x64/0xc0
[ 569.245655] kvm_nested_s2_ptdump_remove_debugfs+0x20/0x48
[ 569.245960] kvm_arch_flush_shadow_all+0x4c/0xc0
[ 569.246100] kvm_mmu_notifier_release+0x3c/0x90
[ 569.246344] mmu_notifier_unregister+0x68/0x148
[ 569.246594] kvm_destroy_vm+0x130/0x2d8
[ 569.246829] kvm_device_release+0xf8/0x170
[ 569.246969] __fput+0xf4/0x350
[ 569.247147] fput_close_sync+0x4c/0x138
[ 569.247291] __arm64_sys_close+0x44/0xa0
[ 569.247493] invoke_syscall+0xa8/0x138
[ 569.247727] el0_svc_common.constprop.0+0x4c/0x140
[ 569.248059] do_el0_svc+0x28/0x58
[ 569.248236] el0_svc+0x48/0x218
[ 569.248420] el0t_64_sync_handler+0xc0/0x108
[ 569.248690] el0t_64_sync+0x1b4/0x1b8
[ 569.249737] Code: b9000820 d503201f d2800000 d2800021 (c8e07e61)
[ 569.250624] ---[ end trace 0000000000000000 ]---
[ 569.251589] note: shadow_stage2[824] exited with preempt_count 1
[ 569.253677] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[ 569.254391] Mem abort info:
[ 569.254416] ESR = 0x0000000096000046
[ 569.254436] EC = 0x25: DABT (current EL), IL = 32 bits
[ 569.254479] SET = 0, FnV = 0
[ 569.254493] EA = 0, S1PTW = 0
[ 569.254506] FSC = 0x06: level 2 translation fault
[ 569.254522] Data abort info:
[ 569.254530] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
[ 569.254544] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 569.254559] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 569.254574] user pgtable: 4k pages, 48-bit VAs, pgdp=000000006dce3000
[ 569.254602] [0000000000000098] pgd=0800000048b63403, p4d=0800000048b63403, pud=0800000048b7f403, pmd=0000000000000000
[ 569.254709] Internal error: Oops: 0000000096000046 [#2] SMP
[ 569.257747] Modules linked in:
[ 569.258124] CPU: 1 UID: 0 PID: 824 Comm: shadow_stage2 Tainted: G D 7.1.0-rc4+ #59 PREEMPT(full)
[ 569.258642] Tainted: [D]=DIE
[ 569.258862] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2ubuntu0.7 11/27/2025
[ 569.259232] pstate: 60402009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 569.259549] pc : down_write+0x50/0xe8
[ 569.259814] lr : down_write+0x34/0xe8
[ 569.259960] sp : ffff80008252b310
[ 569.260175] x29: ffff80008252b310 x28: 0000000000000000 x27: 0000000040000200
[ 569.260507] x26: 0000000000000200 x25: ffffd1bf542891a0 x24: 0000000000000001
[ 569.260891] x23: 0000000000000098 x22: ffff000000637480 x21: ffffd1bf57abc518
[ 569.261278] x20: 0000000000000000 x19: 0000000000000098 x18: ffff80008253d138
[ 569.261652] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 569.262180] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 569.262572] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd1bf5532388c
[ 569.263299] x8 : ffff80008252b508 x7 : 0000000000000000 x6 : 0000000000000000
[ 569.263950] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 569.264428] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000
[ 569.264799] Call trace:
[ 569.265039] down_write+0x50/0xe8 (P)
[ 569.265441] __simple_recursive_removal+0x68/0x230
[ 569.265817] simple_recursive_removal+0x20/0x50
[ 569.266132] debugfs_remove+0x64/0xc0
[ 569.266411] kvm_nested_s2_ptdump_remove_debugfs+0x20/0x48
[ 569.266782] kvm_arch_flush_shadow_all+0x4c/0xc0
[ 569.267059] kvm_mmu_notifier_release+0x3c/0x90
[ 569.267564] __mmu_notifier_release+0x88/0x2a0
[ 569.267736] exit_mmap+0x430/0x490
[ 569.267943] __mmput+0x3c/0x178
[ 569.268068] mmput+0xa4/0xd8
[ 569.268221] do_exit+0x274/0xb00
[ 569.268335] make_task_dead+0x98/0x1f0
[ 569.268634] die+0x194/0x1a0
[ 569.268893] die_kernel_fault+0x1d0/0x3c0
[ 569.269139] __do_kernel_fault+0x280/0x290
[ 569.269348] do_page_fault+0x128/0x7d8
[ 569.269550] do_translation_fault+0x74/0xc0
[ 569.269767] do_mem_abort+0x50/0xd0
[ 569.269945] el1_abort+0x44/0x80
[ 569.270122] el1h_64_sync_handler+0x54/0xd0
[ 569.270306] el1h_64_sync+0x80/0x88
[ 569.270683] down_write+0x50/0xe8 (P)
[ 569.270997] __simple_recursive_removal+0x68/0x230
[ 569.271217] simple_recursive_removal+0x20/0x50
[ 569.271704] debugfs_remove+0x64/0xc0
[ 569.271948] kvm_nested_s2_ptdump_remove_debugfs+0x20/0x48
[ 569.272212] kvm_arch_flush_shadow_all+0x4c/0xc0
[ 569.272510] kvm_mmu_notifier_release+0x3c/0x90
[ 569.272731] mmu_notifier_unregister+0x68/0x148
[ 569.272960] kvm_destroy_vm+0x130/0x2d8
[ 569.273210] kvm_device_release+0xf8/0x170
[ 569.273490] __fput+0xf4/0x350
[ 569.273748] fput_close_sync+0x4c/0x138
[ 569.274023] __arm64_sys_close+0x44/0xa0
[ 569.274289] invoke_syscall+0xa8/0x138
[ 569.274560] el0_svc_common.constprop.0+0x4c/0x140
[ 569.274838] do_el0_svc+0x28/0x58
[ 569.275066] el0_svc+0x48/0x218
[ 569.275321] el0t_64_sync_handler+0xc0/0x108
[ 569.275556] el0t_64_sync+0x1b4/0x1b8
[ 569.275844] Code: b9000820 d503201f d2800000 d2800021 (c8e07e61)
[ 569.276068] ---[ end trace 0000000000000000 ]---
[ 569.277042] note: shadow_stage2[824] exited with preempt_count 1
[ 569.277234] Fixing recursive fault but reboot is needed!
the kernel is based off of kvmarm/fixes, applied your series and
Hyunwoo's patch as well. Could you take a look at this?
Thanks,
Itaru.
>
^ 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