* Re: [PATCH 5/8] iommu/qcom: Publish pgtbl_ops before releasing init_mutex
From: Konrad Dybcio @ 2026-06-23 16:15 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-6-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> qcom_domain->pgtbl_ops was assigned after mutex_unlock(). Another thread
> calling qcom_iommu_init_domain() would see qcom_domain->iommu already set
> (domain fully initialized) and skip re-initialization under the mutex.
> If it then called qcom_iommu_map() before the first thread set pgtbl_ops,
> it would observe a NULL ops pointer and return -ENODEV for valid mappings.
>
> Move the assignment to before mutex_unlock() so that once the mutex is
> released the domain is fully visible to concurrent operations.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/qcom_iommu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> index b6ce85f7f923..40fb0408dc07 100644
> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> @@ -306,13 +306,12 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
> ctx->domain = domain;
> }
>
> - mutex_unlock(&qcom_domain->init_mutex);
> -
> /* Publish page table ops for map/unmap */
> qcom_domain->pgtbl_ops = pgtbl_ops;
>
> - return 0;
> + mutex_unlock(&qcom_domain->init_mutex);
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
even better, we could probably just wrap this in guard(mutex) now
Konrad
^ permalink raw reply
* Re: [PATCH 4/8] iommu/qcom: Fix pgtbl_ops leak in qcom_iommu_init_domain() error path
From: Konrad Dybcio @ 2026-06-23 16:09 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-5-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> alloc_io_pgtable_ops() can succeed and then qcom_scm_restore_sec_cfg()
> can fail for one of the context banks. The goto out_clear_iommu path
> only cleared qcom_domain->iommu; the locally allocated pgtbl_ops was
> never freed, leaking it permanently since qcom_domain->pgtbl_ops is only
> assigned on the success path.
>
> free_io_pgtable_ops() safely handles a NULL argument (covers the case
> where alloc_io_pgtable_ops() itself failed), so add it unconditionally in
> the out_clear_iommu handler.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/qcom_iommu.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> index 4e714a8e1fac..b6ce85f7f923 100644
> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> @@ -314,6 +314,7 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
> return 0;
>
> out_clear_iommu:
> + free_io_pgtable_ops(pgtbl_ops);
This label also jumped to when alloc_io_pgtable_ops() succeeds,
but there's a nullcheck inside, so i guess it's fine
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RESEND 3/3] dmaengine: xilinx_dma: Optimize control register write and channel start logic for AXIDMA and MCDMA in corresponding start_transfer()
From: Pandey, Radhey Shyam @ 2026-06-23 16:08 UTC (permalink / raw)
To: Suraj Gupta, vkoul, Frank.Li, michal.simek, linux-kernel
Cc: dmaengine, linux-arm-kernel, srinivas.neeli, dev
In-Reply-To: <20260620203417.4000360-4-suraj.gupta2@amd.com>
On 6/21/2026 2:04 AM, Suraj Gupta wrote:
> Optimize AXI DMA control register programming by consolidating
> coalesce count and delay configuration into a single register write.
> Previously, the coalesce count was written separately from the delay
> configuration, resulting in two register writes. Combine these into
> one write operation to reduce bus overhead.
> Additionally, avoid redundant channel starts in xilinx_dma_start_transfer()
> and xilinx_mcdma_start_transfer() by only calling xilinx_dma_start() when
> the channel is actually idle.
>
> Tested-by: Folker Schwesinger <dev@folker-schwesinger.de>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> drivers/dma/xilinx/xilinx_dma.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 35b553ee3205..aa3dee0dc2fc 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1593,7 +1593,6 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> reg &= ~XILINX_DMA_CR_COALESCE_MAX;
> reg |= chan->desc_pendingcount <<
> XILINX_DMA_CR_COALESCE_SHIFT;
> - dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
> }
>
> if (chan->has_sg && list_empty(&chan->active_list))
> @@ -1604,7 +1603,8 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> reg |= XILINX_DMA_DMAXR_ALL_IRQ_MASK;
> dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
>
> - xilinx_dma_start(chan);
> + if (chan->idle)
> + xilinx_dma_start(chan);
>
> if (chan->err)
> return;
> @@ -1693,7 +1693,8 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
> reg |= XILINX_MCDMA_CR_RUNSTOP_MASK;
> dma_ctrl_write(chan, XILINX_MCDMA_CHAN_CR_OFFSET(chan->tdest), reg);
>
> - xilinx_dma_start(chan);
> + if (chan->idle)
> + xilinx_dma_start(chan);
>
> if (chan->err)
> return;
^ permalink raw reply
* [PATCH] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-23 16:03 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, kvmarm
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
linux-arm-kernel, linux-kernel, Bradley Morgan, stable
pKVM keeps its own mapping list for stage 2 operations. Its flush path
uses that list directly, so it lost the PTE attribute check done by the
generic stage 2 walker.
Record whether a mapping is cacheable and skip cache maintenance for
mappings that are not cacheable.
Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
arch/arm64/include/asm/kvm_pkvm.h | 1 +
arch/arm64/kvm/pkvm.c | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
index 74fedd9c5ff0..d9dd8239910d 100644
--- a/arch/arm64/include/asm/kvm_pkvm.h
+++ b/arch/arm64/include/asm/kvm_pkvm.h
@@ -196,6 +196,7 @@ struct pkvm_mapping {
u64 gfn;
u64 pfn;
u64 nr_pages;
+ bool cacheable;
u64 __subtree_last; /* Internal member for interval tree */
};
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 428723b1b0f5..105ab1258066 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -473,6 +473,8 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
mapping->gfn = gfn;
mapping->pfn = pfn;
mapping->nr_pages = size / PAGE_SIZE;
+ mapping->cacheable = !(prot & (KVM_PGTABLE_PROT_DEVICE |
+ KVM_PGTABLE_PROT_NORMAL_NC));
pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
return ret;
@@ -517,9 +519,13 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable *pgt, u64 addr, u64 size)
struct pkvm_mapping *mapping;
lockdep_assert_held(&kvm->mmu_lock);
- for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
+ for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
+ if (!mapping->cacheable)
+ continue;
+
__clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
PAGE_SIZE * mapping->nr_pages);
+ }
return 0;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 3/8] iommu/qcom: Check pm_runtime_resume_and_get() return in probe
From: Konrad Dybcio @ 2026-06-23 16:02 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-4-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> The SMMU_INTR_SEL_NS register write in qcom_iommu_device_probe() uses
> pm_runtime_get_sync() without checking the return value. If runtime
> resume fails the subsequent writel_relaxed() would access hardware with
> clocks potentially disabled.
>
> Switch to pm_runtime_resume_and_get() which handles the usage-count
> cleanup on failure, check the return value, and unwind the already
> registered iommu device on error.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/8] iommu/qcom: Fix missing pm_runtime_disable() in qcom_iommu_device_remove()
From: Konrad Dybcio @ 2026-06-23 16:00 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-3-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> qcom_iommu_device_probe() calls pm_runtime_enable() but
> qcom_iommu_device_remove() only calls pm_runtime_force_suspend() without
> a matching pm_runtime_disable(). This leaves runtime PM enabled after the
> driver unbinds, which can cause issues on rebind or if any code races to
> resume the device after removal.
>
> Add pm_runtime_disable() in the remove path to balance the enable in probe.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/qcom_iommu.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> index 09f2ee6be988..cb43276f4a39 100644
> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> @@ -878,6 +878,7 @@ static void qcom_iommu_device_remove(struct platform_device *pdev)
> struct qcom_iommu_dev *qcom_iommu = platform_get_drvdata(pdev);
>
> pm_runtime_force_suspend(&pdev->dev);
> + pm_runtime_disable(&pdev->dev);
devm_ would be neater
Konrad
^ permalink raw reply
* Re: [PATCH 1/8] iommu/qcom: Fix inverted fault report check in qcom_iommu_fault()
From: Konrad Dybcio @ 2026-06-23 16:00 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-2-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> report_iommu_fault() returns 0 when a fault handler successfully handles
> the fault, and -ENOSYS when no handler is installed. The condition
> '!report_iommu_fault()' evaluates to true (printing "Unhandled context
> fault") precisely when the fault *was* handled, and stays silent when no
> handler is present — the opposite of what is intended.
>
> Remove the '!' so the driver logs unhandled faults correctly.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/qcom_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> index 32efef69e72d..09f2ee6be988 100644
> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> @@ -200,7 +200,7 @@ static irqreturn_t qcom_iommu_fault(int irq, void *dev)
> fsynr = iommu_readl(ctx, ARM_SMMU_CB_FSYNR0);
> iova = iommu_readq(ctx, ARM_SMMU_CB_FAR);
>
> - if (!report_iommu_fault(ctx->domain, ctx->dev, iova, 0)) {
> + if (report_iommu_fault(ctx->domain, ctx->dev, iova, 0)) {
Absolutely hilarious
Fixes: 049541e178d5 ("iommu: qcom: wire up fault handler")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
> dev_err_ratelimited(ctx->dev,
> "Unhandled context fault: fsr=0x%x, "
> "iova=0x%016llx, fsynr=0x%x, cb=%d\n",
^ permalink raw reply
* Re: [PATCH RESEND 1/3] dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers
From: Pandey, Radhey Shyam @ 2026-06-23 15:59 UTC (permalink / raw)
To: Suraj Gupta, vkoul, Frank.Li, michal.simek, linux-kernel
Cc: dmaengine, linux-arm-kernel, srinivas.neeli, dev
In-Reply-To: <20260620203417.4000360-2-suraj.gupta2@amd.com>
On 6/21/2026 2:04 AM, Suraj Gupta wrote:
> Fix a race condition in AXIDMA and MCDMA irq handlers where the channel
> could be incorrectly marked as idle and attempt spurious transfers when
> descriptors are still being processed.
>
> The issue occurs when:
> 1. Multiple descriptors are queued and active.
> 2. An interrupt fires after completing some descriptors.
> 3. xilinx_dma_complete_descriptor() moves completed descriptors to
> done_list.
> 4. Channel is marked idle and start_transfer() is called even though
> active_list still contains unprocessed descriptors.
> 5. This leads to premature transfer attempts and potential descriptor
> corruption or missed completions.
>
> Only mark the channel as idle and start new transfers when the active list
> is actually empty, ensuring proper channel state management and avoiding
> spurious transfer attempts.
>
> Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine")
> Tested-by: Folker Schwesinger <dev@folker-schwesinger.de>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
Checked shashiko report and it points to 3 existing issues
which should be handled in separate series.
For this patch.
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> drivers/dma/xilinx/xilinx_dma.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 404235c17353..ca396b709742 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1893,8 +1893,10 @@ static irqreturn_t xilinx_mcdma_irq_handler(int irq, void *data)
> if (status & XILINX_MCDMA_IRQ_IOC_MASK) {
> spin_lock(&chan->lock);
> xilinx_dma_complete_descriptor(chan);
> - chan->idle = true;
> - chan->start_transfer(chan);
> + if (list_empty(&chan->active_list)) {
> + chan->idle = true;
> + chan->start_transfer(chan);
> + }
> spin_unlock(&chan->lock);
> }
>
> @@ -1950,8 +1952,10 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void *data)
> XILINX_DMA_DMASR_DLY_CNT_IRQ)) {
> spin_lock(&chan->lock);
> xilinx_dma_complete_descriptor(chan);
> - chan->idle = true;
> - chan->start_transfer(chan);
> + if (list_empty(&chan->active_list)) {
> + chan->idle = true;
> + chan->start_transfer(chan);
> + }
> spin_unlock(&chan->lock);
> }
>
^ permalink raw reply
* Re: [GIT PULL] Mailbox changes for v7.2
From: pr-tracker-bot @ 2026-06-23 15:40 UTC (permalink / raw)
To: Jassi Brar; +Cc: Linus Torvalds, Linux Kernel Mailing List, linux-arm-kernel
In-Reply-To: <CABb+yY3Tns7SmNU+_iSKcnrg+Muy5eOTNHn49nj+uv73VHNgTw@mail.gmail.com>
The pull request you sent on Mon, 22 Jun 2026 13:37:57 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git tags/mailbox-v7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/515db262143e48f09b5dce07bc0db67b8b4d6a73
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Konrad Dybcio @ 2026-06-23 15:50 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-1-37e2ee8df9da@proton.me>
On 6/23/26 2:54 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Both of these changes allow the framebuffer to show upon boot and let
> the mdss driver take over afterwards.
> Before, none of these actions were possible. Only mdss takeover was
> possible, but screen had to be turned off first.
>
> OLE configuration may have been a misinterpretation... that's not
> something that's done on the downstream driver.
>
> Changing disp_cc_mdss_mdp_clk_src from clk_rcg2_shared_ops to
> clk_rcg2_shared_no_init_park_ops fixes this warning as well:
[...]
> drivers/clk/qcom/dispcc-sm8450.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/qcom/dispcc-sm8450.c b/drivers/clk/qcom/dispcc-sm8450.c
> index 2e91332dd92a..b99d3eb5e195 100644
> --- a/drivers/clk/qcom/dispcc-sm8450.c
> +++ b/drivers/clk/qcom/dispcc-sm8450.c
> @@ -614,7 +614,7 @@ static struct clk_rcg2 disp_cc_mdss_mdp_clk_src = {
> .parent_data = disp_cc_parent_data_5,
> .num_parents = ARRAY_SIZE(disp_cc_parent_data_5),
> .flags = CLK_SET_RATE_PARENT,
> - .ops = &clk_rcg2_shared_ops,
> + .ops = &clk_rcg2_shared_no_init_park_ops,
> },
> };
>
> @@ -1824,8 +1824,8 @@ static int disp_cc_sm8450_probe(struct platform_device *pdev)
> disp_cc_pll1.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID_OLE];
> disp_cc_pll1.clkr.hw.init = &sm8475_disp_cc_pll1_init;
>
> - clk_lucid_ole_pll_configure(&disp_cc_pll0, regmap, &sm8475_disp_cc_pll0_config);
> - clk_lucid_ole_pll_configure(&disp_cc_pll1, regmap, &sm8475_disp_cc_pll1_config);
> + clk_lucid_evo_pll_configure(&disp_cc_pll0, regmap, &sm8475_disp_cc_pll0_config);
> + clk_lucid_evo_pll_configure(&disp_cc_pll1, regmap, &sm8475_disp_cc_pll1_config);
> } else {
> clk_lucid_evo_pll_configure(&disp_cc_pll0, regmap, &disp_cc_pll0_config);
> clk_lucid_evo_pll_configure(&disp_cc_pll1, regmap, &disp_cc_pll1_config);
This can also be fixed by migrating to use qcom_cc_driver_data,
which takes a list of alpha PLLs to be configured, and thenthere's
a switch-statement in clk-alpha-pll.c that always assigns the
correct function
Konrad
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Fuad Tabba @ 2026-06-23 15:46 UTC (permalink / raw)
To: Bradley Morgan
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <54A2BB77-5E81-4730-82A1-DB457118784C@grrlz.net>
Hi Bradley,
On Tue, 23 Jun 2026 at 16:11, Bradley Morgan <include@grrlz.net> wrote:
>
> On June 23, 2026 4:03:30 PM GMT+01:00, Fuad Tabba <fuad.tabba@linux.dev>
> wrote:
> >On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
> >>
> >> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org>
> >wrote:
> >> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> >> >> Protected guest faults charge long term pins to the VM's mm. Teardown
> >> >> can run later from file release, where current->mm may be unrelated.
> >> >>
> >> >> Drop the charge from kvm->mm instead.
> >> >>
> >> >>
> >> >
> >> >Applied to fixes, thanks!
> >> >
> >> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> >> > commit: d098bb75d14fde2f12155f1a95ec0168160867ce
> >> >
> >> >Cheers,
> >> >
> >> > M.
> >> >
> >>
> >>
> >> Hey, which tree did you apply it to?
> >
> >https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
> >
> >/fuad
> >
> >>
> >>
> >> Thanks!
> >
>
> Thanks fuad.
>
> May I ask if this would be put onto ACK?
Yes, I'll pick it into ACK.
Cheers,
/fuad
>
> Since this affects pixel devices.
>
> (E.g, my pixel 7....)
>
> Thanks!
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Chen-Yu Tsai @ 2026-06-23 15:42 UTC (permalink / raw)
To: Jerome Brunet, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree
In-Reply-To: <1j1pe7elxm.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:46 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 20:37, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:03 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> The RTC module in the Allwinner A733 SoC is functionally compatible with
> >> the sun6i RTC, but its internal Clock Control Unit (CCU) has significant
> >> changes.
> >>
> >> The A733 supports selecting the oscillator between three frequencies:
> >> 19.2MHz, 24MHz, and 26MHz. The RTC CCU relies on hardware to detect
> >> which frequency is actually used on the board. By defining all three
> >> frequencies as fixed-clocks in the device tree, the driver can identify
> >> the hardware-detected frequency and expose it to the rest of the system.
> >
> > No. The board device tree shall have the exact and correct frequency
> > defined in the external crystal device node. The operating system can
> > use the hardware-detected frequency to "fix" the in-system representation
> > if it is off.
> >
> >> Additionally, the A733 RTC CCU provides several new DCXO gate clocks for
> >> specific modules, including SerDes, HDMI, and UFS.
> >>
> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> >> ---
> >> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 ++++++++++++++++++++--
> >> include/dt-bindings/clock/sun60i-a733-rtc.h | 16 +++++++++
> >> 2 files changed, 52 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> index 9df5cdb6f63f..b18431955783 100644
> >> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> @@ -26,6 +26,7 @@ properties:
> >> - allwinner,sun50i-h6-rtc
> >> - allwinner,sun50i-h616-rtc
> >> - allwinner,sun50i-r329-rtc
> >> + - allwinner,sun60i-a733-rtc
> >> - items:
> >> - const: allwinner,sun50i-a64-rtc
> >> - const: allwinner,sun8i-h3-rtc
> >> @@ -46,11 +47,11 @@ properties:
> >>
> >> clocks:
> >> minItems: 1
> >> - maxItems: 4
> >> + maxItems: 6
> >>
> >> clock-names:
> >> minItems: 1
> >> - maxItems: 4
> >> + maxItems: 6
> >>
> >> clock-output-names:
> >> minItems: 1
> >> @@ -156,6 +157,38 @@ allOf:
> >> - clocks
> >> - clock-names
> >>
> >> + - if:
> >> + properties:
> >> + compatible:
> >> + contains:
> >> + const: allwinner,sun60i-a733-rtc
> >> +
> >> + then:
> >> + properties:
> >> + clocks:
> >> + minItems: 5
> >> + items:
> >> + - description: Bus clock for register access
> >
> >> + - description: 19.2 MHz oscillator
> >> + - description: 24 MHz oscillator
> >> + - description: 26 MHz oscillator
> >
> > No. There is only one input. As in there is only one set of pins for the
> > DCXO. The inputs are the same as on R329 / A523. Just use that list.
> >
> >> + - description: AHB parent for internal SPI clock
> >> + - description: External 32768 Hz oscillator
> >> +
> >> + clock-names:
> >> + minItems: 5
> >> + items:
> >> + - const: bus
> >> + - const: osc19M
> >> + - const: osc24M
> >> + - const: osc26M
> >> + - const: ahb
> >> + - const: ext-osc32k
> >> +
> >> + required:
> >> + - clocks
> >> + - clock-names
> >> +
> >> - if:
> >> properties:
> >> compatible:
> >> @@ -164,6 +197,7 @@ allOf:
> >> - allwinner,sun8i-r40-rtc
> >> - allwinner,sun50i-h616-rtc
> >> - allwinner,sun50i-r329-rtc
> >> + - allwinner,sun60i-a733-rtc
> >>
> >> then:
> >> properties:
> >> diff --git a/include/dt-bindings/clock/sun60i-a733-rtc.h b/include/dt-bindings/clock/sun60i-a733-rtc.h
> >> new file mode 100644
> >> index 000000000000..8a2b5facad73
> >> --- /dev/null
> >> +++ b/include/dt-bindings/clock/sun60i-a733-rtc.h
> >> @@ -0,0 +1,16 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
> >> +
> >> +#ifndef _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
> >> +#define _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
> >> +
> >> +#define CLK_IOSC 0
> >> +#define CLK_OSC32K 1
> >> +#define CLK_HOSC 2
> >
> > The DCXO enable control has been present since at least the H6. We just
> > never added it, as we would never disable it anyway.
> >
> > If you compare the RTC clock trees of the A733 and A523, the only addition
> > besides the new gates seems to be the LOSC auto selection. But even that
> > is just an illusion, as the A523 has the same registers for that.
> >
> > One could say the A733 RTC is almost backward compatible to the A523, if
> > not for the two fastboot registers the A523 has at 0x120 and 0x124.
> >
> > So I ask that you try to integrate the differences into the existing
> > driver and bindings. You can tweak and export internal clks if you
> > need.
>
> I'd like to help with that. I think it is doable but I have a question
> regarding the binding of the existing driver, more precisely their usage
> here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c?h=v7.1#n370
>
> Clock indexes are supposed to be stable in DT (AFAIK) but with the code
> linked the external 32k is at:
>
> * "ext-32k" - so index 3 - if "clock-names" is present
> * index 0 if clock names is not present
>
> ... but index 0 is supposed to be the bus clock according the binding
> doc, whether "clock-names" is there or not :/
>
> So what are those old r329 bindings ? is there a documentation defining
> them somewhere ?
You can look at
8487614a8a8a dt-bindings: rtc: sun6i: Add H616, R329, and D1 support
In hindsight maybe the two bindings should be separate. The old SoCs
did not have all these clock inputs from the main clock controller.
The only input it could possibly take was the external 32k crystal.
> Cleaning that part would help with A733 addition in the existing driver
> I think
Yeah. Also, we can treat the bindings and drivers separately. We could
have two bindings but one common driver, or vice versa. As you pointed
out, the bindings are a bit messed up, so we could consider separating
them.
If we end up with separate binding header files, maybe we could use
a different prefix for the new ones so they don't collide? That way
the driver could maybe still be shared?
As for whether to share the headers, I think they should be treated
as part of the binding, so if the bindings are shared, then they can
be shared as well; if the bindings are separate, then they should be
completely separate files as well.
And sorry for the late reply.
Thanks
ChenYu
> >
> >> +#define CLK_RTC_32K 3
> >
> > AFAICT besides being an internal clock, this is also fed to GPIO for
> > debounce? We probably need to expose this on the A523 as well.
> >
> >
> > Thanks
> > ChenYu
> >
> >
> >> +#define CLK_OSC32K_FANOUT 4
> >> +#define CLK_HOSC_SERDES1 5
> >> +#define CLK_HOSC_SERDES0 6
> >> +#define CLK_HOSC_HDMI 7
> >> +#define CLK_HOSC_UFS 8
> >> +
> >> +#endif /* _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_ */
> >>
> >> --
> >> 2.52.0
> >>
> >>
>
> --
> Jerome
>
^ permalink raw reply
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Krzysztof Kozlowski @ 2026-06-23 15:39 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-1-37e2ee8df9da@proton.me>
On 23/06/2026 02:54, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Both of these changes allow the framebuffer to show upon boot and let
> the mdss driver take over afterwards.
> Before, none of these actions were possible. Only mdss takeover was
> possible, but screen had to be turned off first.
>
> OLE configuration may have been a misinterpretation... that's not
> something that's done on the downstream driver.
>
> Changing disp_cc_mdss_mdp_clk_src from clk_rcg2_shared_ops to
> clk_rcg2_shared_no_init_park_ops fixes this warning as well:
These should be two separate commits, if I understand correctly.
Please use also Fixes tag.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: allwinner: add Allwinner A733 SoC
From: Jerome Brunet @ 2026-06-23 15:35 UTC (permalink / raw)
To: Enzo Adriano via B4 Relay
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson,
enzo.adriano.code, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-mmc
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-3-7787c94681db@gmail.com>
On sam. 13 juin 2026 at 05:42, Enzo Adriano via B4 Relay <devnull+enzo.adriano.code.gmail.com@kernel.org> wrote:
> From: Enzo Adriano <enzo.adriano.code@gmail.com>
>
> Add the initial A733 SoC description with CPUs, timers, interrupt
> controller, clocks, pinctrl, UART0, and MMC0.
>
> Keep peripherals disabled by default. Board DTS files can enable only the
> devices that are proven on their hardware.
>
> Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi | 198 +++++++++++++++++++++++++
> 1 file changed, 198 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi b/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi
> new file mode 100644
> index 000000000000..3721aa9e8573
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi
> @@ -0,0 +1,198 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/sun60i-a733-ccu.h>
> +#include <dt-bindings/reset/sun60i-a733-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x000>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu1: cpu@100 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x100>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu2: cpu@200 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x200>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu3: cpu@300 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x300>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu4: cpu@400 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x400>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu5: cpu@500 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x500>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu6: cpu@600 {
> + compatible = "arm,cortex-a76";
> + device_type = "cpu";
> + reg = <0x600>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> + };
> +
> + cpu7: cpu@700 {
> + compatible = "arm,cortex-a76";
> + device_type = "cpu";
> + reg = <0x700>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> + };
> + };
> +
> + osc24M: osc24M-clk {
Note A733 supports 19.2MHz, 24MHz and 26MHz xtals apparently.
The A7S and A7A do have a 26MHz xtal according to the schematics.
While this might be fine in the SoC dtsi, your are missing something in
your board dts to change the xtal rate, at least.
Also the node and clock name are a bit misleading now.
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: osc32k-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
I think this is the ext32k supposed to feed the rtc ccu ...
> + };
> +
> + iosc: internal-osc-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <16000000>;
> + clock-output-names = "iosc";
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0", "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x40000000>;
> +
> + pio: pinctrl@2000000 {
> + compatible = "allwinner,sun60i-a733-pinctrl";
> + reg = <0x02000000 0x600>;
> + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_APB1>, <&osc24M>, <&osc32k>;
> + clock-names = "apb", "hosc", "losc";
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + mmc0_pins: mmc0-pins {
> + pins = "PF0", "PF1", "PF2",
> + "PF3", "PF4", "PF5";
> + function = "mmc0";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> + };
> +
> + ccu: clock-controller@2002000 {
> + compatible = "allwinner,sun60i-a733-ccu";
> + reg = <0x02002000 0x2000>;
> + clocks = <&osc24M>, <&osc32k>, <&iosc>;
^
... not directly the main CCU.
> + clock-names = "hosc", "losc", "iosc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + uart0: serial@2500000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x02500000 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + gic: interrupt-controller@3400000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x03400000 0x10000>,
> + <0x03460000 0x100000>;
> + };
> +
> + mmc0: mmc@4020000 {
> + compatible = "allwinner,sun60i-a733-mmc",
> + "allwinner,sun20i-d1-mmc";
> + reg = <0x04020000 0x1000>;
> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC0>;
> + reset-names = "ahb";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + max-frequency = <200000000>;
> + cap-sd-highspeed;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +};
--
Jerome
^ permalink raw reply
* [PATCH] spi: imx: reconfigure for PIO when DMA cannot be started
From: Javier Fernandez Pastrana @ 2026-06-23 15:32 UTC (permalink / raw)
To: Mark Brown, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Carlos Song, linux-spi, imx, linux-arm-kernel,
linux-kernel
Cc: javier.pastrana, stable
When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the
SDMA watermarks.
If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single()
returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and
falls back to PIO. The dynamic-burst DMA path uses its own bounce
buffers instead of the SPI core's mapping, so xfer->{tx,rx}_sg_mapped
are not set and the core's DMA->PIO retry is skipped; the driver falls
back to PIO internally. But none of the DMA-mode configuration is
undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst
length and dynamic_burst cleared, and the transferred data is corrupted.
This is easily hit on i.MX8MP boards that describe ECSPI DMA in the
device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin):
every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then
returns shifted TPM2_GetCapability data, is flagged "field failure
mode", /dev/tpmrm0 is never created.
Mark the controller PIO-only (controller->fallback) and re-run
spi_imx_setupxfer() before falling back, so the ECSPI is reconfigured
exactly like a normal PIO transfer.
Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode")
Cc: stable@vger.kernel.org
Signed-off-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
---
drivers/spi/spi-imx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 480d1e8b281f..64c78bd79d7d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -2153,6 +2153,8 @@ static int spi_imx_transfer_one(struct spi_controller *controller,
ret = spi_imx_dma_transfer(spi_imx, transfer);
if (transfer->error & SPI_TRANS_FAIL_NO_START) {
spi_imx->usedma = false;
+ controller->fallback = true;
+ spi_imx_setupxfer(spi, transfer);
if (spi_imx->target_mode)
return spi_imx_pio_transfer_target(spi, transfer);
else
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Add tracepoint for EVTQ events
From: Robin Murphy @ 2026-06-23 15:31 UTC (permalink / raw)
To: Chen Jun, will, joro, linux-kernel, linux-arm-kernel; +Cc: zhangyuwei20
In-Reply-To: <20260613130007.18563-1-chenjun102@huawei.com>
On 13/06/2026 2:00 pm, Chen Jun wrote:
> Events reported by the SMMU can severely impact accelerator
> performance. Currently, only events that the SMMU fails to handle are
> printed to the kernel log, leaving most events invisible to users.
> To analyze and optimize accelerator performance, complete visibility
> into all SMMU-reported events is required.
What events, exactly? AFAICS the only events we should expect to handle
"invisibly", without being some unexpected error condition worth
screaming about, would be stalls for SVA page faults, and if SVA isn't
generically accounting page faults itself then I would imagine it
probably should.
Thanks,
Robin.
> Add a tracepoint in the EVTQ interrupt handler to capture every
> event record reported by the SMMU. This allows users to collect all
> event information via ftrace/perf for further analysis, complementing
> the existing event decoder and error dump which only cover a subset
> of events.
>
> Signed-off-by: Chen Jun <chenjun102@huawei.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/Makefile | 2 +-
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++
> drivers/iommu/arm/arm-smmu-v3/trace.c | 9 ++++
> drivers/iommu/arm/arm-smmu-v3/trace.h | 53 +++++++++++++++++++++
> 4 files changed, 66 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iommu/arm/arm-smmu-v3/trace.c
> create mode 100644 drivers/iommu/arm/arm-smmu-v3/trace.h
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/Makefile b/drivers/iommu/arm/arm-smmu-v3/Makefile
> index 493a659cc66b..63a8d71bfc93 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/Makefile
> +++ b/drivers/iommu/arm/arm-smmu-v3/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_ARM_SMMU_V3) += arm_smmu_v3.o
> -arm_smmu_v3-y := arm-smmu-v3.o
> +arm_smmu_v3-y := arm-smmu-v3.o trace.o
> arm_smmu_v3-$(CONFIG_ARM_SMMU_V3_IOMMUFD) += arm-smmu-v3-iommufd.o
> arm_smmu_v3-$(CONFIG_ARM_SMMU_V3_SVA) += arm-smmu-v3-sva.o
> arm_smmu_v3-$(CONFIG_TEGRA241_CMDQV) += tegra241-cmdqv.o
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f0..85e6c25b73ed 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -34,6 +34,8 @@
> #include "arm-smmu-v3.h"
> #include "../../dma-iommu.h"
>
> +#include "trace.h"
> +
> static bool disable_msipolling;
> module_param(disable_msipolling, bool, 0444);
> MODULE_PARM_DESC(disable_msipolling,
> @@ -2271,6 +2273,7 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
>
> do {
> while (!queue_remove_raw(q, evt)) {
> + trace_smmu_evtq_event(smmu, evt);
> arm_smmu_decode_event(smmu, evt, &event);
> if (arm_smmu_handle_event(smmu, evt, &event))
> arm_smmu_dump_event(smmu, evt, &event, &rs);
> diff --git a/drivers/iommu/arm/arm-smmu-v3/trace.c b/drivers/iommu/arm/arm-smmu-v3/trace.c
> new file mode 100644
> index 000000000000..77378698b1a3
> --- /dev/null
> +++ b/drivers/iommu/arm/arm-smmu-v3/trace.c
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ARM SMMUv3 trace support
> + *
> + * Copyright (c) 2026 OpenCloudOS / openEuler
> + */
> +
> +#define CREATE_TRACE_POINTS
> +#include "trace.h"
> diff --git a/drivers/iommu/arm/arm-smmu-v3/trace.h b/drivers/iommu/arm/arm-smmu-v3/trace.h
> new file mode 100644
> index 000000000000..7cec8d41745e
> --- /dev/null
> +++ b/drivers/iommu/arm/arm-smmu-v3/trace.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * ARM SMMUv3 trace support
> + *
> + * Copyright (c) 2026 OpenCloudOS / openEuler
> + */
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM arm_smmu_v3
> +
> +#if !defined(_TRACE_ARM_SMMU_V3_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_ARM_SMMU_V3_H
> +
> +#include <linux/tracepoint.h>
> +
> +#include "arm-smmu-v3.h"
> +
> +TRACE_EVENT(smmu_evtq_event,
> +
> + TP_PROTO(struct arm_smmu_device *smmu, u64 *evt),
> +
> + TP_ARGS(smmu, evt),
> +
> + TP_STRUCT__entry(
> + __string(iommu, dev_name(smmu->dev))
> + __field(u64, evt0)
> + __field(u64, evt1)
> + __field(u64, evt2)
> + __field(u64, evt3)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(iommu);
> + __entry->evt0 = evt[0];
> + __entry->evt1 = evt[1];
> + __entry->evt2 = evt[2];
> + __entry->evt3 = evt[3];
> + ),
> +
> + TP_printk("%s evt: 0x%016llx 0x%016llx 0x%016llx 0x%016llx",
> + __get_str(iommu),
> + __entry->evt0, __entry->evt1,
> + __entry->evt2, __entry->evt3)
> +);
> +
> +#endif /* _TRACE_ARM_SMMU_V3_H */
> +
> +/* This part must be outside protection */
> +#undef TRACE_INCLUDE_PATH
> +#undef TRACE_INCLUDE_FILE
> +#define TRACE_INCLUDE_PATH ../../drivers/iommu/arm/arm-smmu-v3/
> +#define TRACE_INCLUDE_FILE trace
> +#include <trace/define_trace.h>
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Chen-Yu Tsai @ 2026-06-23 15:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, André Przywara
In-Reply-To: <1jv7bjd6wi.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:56 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 22:41, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> Add support for the internal CCU found in the RTC module of the Allwinner
> >> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
> >> with older SoCs like the sun6i, the A733 introduces several new features.
> >>
> >> The A733 RTC CCU supports choosing one of three external crystal
> >> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
> >> logic to automatically identify the frequency used on the board and
> >> exports this DCXO signal as the "hosc" clock.
> >>
> >> Furthermore, the driver implements logic to derive a 32kHz reference
> >> from the HOSC. This is achieved through a muxed clock path using fixed
> >> pre-dividers to normalize the different crystal frequencies to ~32kHz.
> >
> > Have you tested whether the actually normalizes the frequency, i.e.
> > selects a different divider based on the DCXO frequency? Otherwise
> > we're just lying about the frequency.
> >
> >> This path reuses the same hardware mux registers as the HOSC clock.
> >>
> >> Additionally, this CCU provides several gate clocks for specific
> >> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
> >> as an auxiliary driver to be bound to the sun6i-rtc driver.
> >>
> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> >> ---
>
> [...]
>
> >> +};
> >> +
> >> +static const struct clk_parent_data hosc_parents[] = {
> >> + { .fw_name = "osc24M" },
> >> + { .fw_name = "osc19M" },
> >> + { .fw_name = "osc26M" },
> >> + { .fw_name = "osc24M" },
> >> +};
> >
> > As mentioned in my reply to the binding, this is wrong. There is only
> > one input.
> >
> > The most you can do is check the rate of the parent clock against the
> > detected one, and _scream_ that the DT is wrong. And maybe override
> > the reported frequency.
> >
> > If you want to do the latter, you could add a new fixed rate gated
> > clock type to our library. You would fill in the rate before the
> > clocks get registered. I probably wouldn't go that far. We want people
> > to have correct hardware descriptions.
> >
> > Funnily enough Allwinner's BSP actually implements a fixed rate gate
> > for the next 24M-to-32k divider clock.
>
> What about implementing the register bellow as a read-only (and
> non-cached) divider using the factors provided by Junhui ? That would be
> an accurate description of the HW I think.
>
> The oscillator gets set in DT and if the output reported past the
> divider is not 32728Hz, you know you've got a problem (bad DT or HW gone
> bad)
>
> With a fixed-rate gate, you may actually end up lying about what
> actually happen, if the HW does not behave as expected.
>
> Do you prefer a fixed-rate gate still or should I try the RO divider
> approach ?
I think either one would work. The RO divider is probably more accurate.
Sorry for the late reply.
ChenYu
^ permalink raw reply
* Re: [PATCH 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Robin Murphy @ 2026-06-23 15:16 UTC (permalink / raw)
To: Marek Szyprowski, Viacheslav Bocharov, Linus Walleij,
Bartosz Golaszewski
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel, linux-rockchip, Heiko Stuebner
In-Reply-To: <184d315b-a0a1-4792-8a40-1b4967025916@samsung.com>
On 11/06/2026 9:26 am, Marek Szyprowski wrote:
> Hi Viachesla,
>
> On 10.06.2026 17:32, Viacheslav Bocharov wrote:
>> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
>> the underlying chip's can_sleep, but under that lock it calls config and
>> direction ops that reach sleeping pinctrl paths. On a controller with
>> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
>> runs from atomic context:
>>
>> BUG: sleeping function called from invalid context
>> ... pinctrl_gpio_set_config <- gpiochip_generic_config
>> <- gpio_shared_proxy_set_config (voting spinlock held)
>> <- ... <- mmc_pwrseq_simple_probe
>>
>> This was reported on Khadas VIM3 and worked around for Amlogic by
>> commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
>> sleeping"), which marked the whole meson controller sleeping. That
>> workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
>> no longer detects devices, because its IRQ-disabled read slot calls the
>> non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
>>
>> Patch 1 fixes the proxy locking generically (always a sleeping mutex).
>> Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
>>
>> Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
>> gating on gpiod_cansleep() change behaviour. No current device needs
>> atomic (non-cansleep) value access on a shared GPIO -- every report
>> (Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
>> (eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
>> which is what the proxy exists to vote on. An alternative that keeps
>> atomic value access (split locking) is possible but adds a second lock
>> and new race windows. I went with the simpler, verified approach and
>> would appreciate guidance on whether the atomic value path must be
>> preserved.
>>
>> The two are a unit: patch 2 must not be applied without patch 1,
>> otherwise the original VIM3 splat returns on boards that share a meson
>> GPIO -- please keep the order. I have not Cc'd stable; I will request
>> stable backports separately once both patches have landed.
>>
>> Viacheslav Bocharov (2):
>> gpio: shared-proxy: always serialize with a sleeping mutex
>> pinctrl: meson: restore non-sleeping GPIO access
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> This probably also affects the similar changes in Rockchip GPIO driver done
> by the following commits:
> 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
> 7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction")
>
> I've checked this patchset with these two reverted and no warning was reported.
If it hadn't already been fixed, then indeed I guess this might make
20cf2aed89ac redundant. However, 7ca497be0016 is still an objective
improvement either way, since that driver never needed to call pinctrl
at all (it was seemingly just an artefact of how the GPIO code was
originally implemented within the pinctrl driver itself).
Thanks,
Robin.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Bradley Morgan @ 2026-06-23 15:11 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <CA+EHjTz+oNerTD3Ygj3EzOA4zm4BKfQYM45ydwVO=2amErkBAQ@mail.gmail.com>
On June 23, 2026 4:03:30 PM GMT+01:00, Fuad Tabba <fuad.tabba@linux.dev>
wrote:
>On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
>>
>> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org>
>wrote:
>> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
>> >> Protected guest faults charge long term pins to the VM's mm. Teardown
>> >> can run later from file release, where current->mm may be unrelated.
>> >>
>> >> Drop the charge from kvm->mm instead.
>> >>
>> >>
>> >
>> >Applied to fixes, thanks!
>> >
>> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
>> > commit: d098bb75d14fde2f12155f1a95ec0168160867ce
>> >
>> >Cheers,
>> >
>> > M.
>> >
>>
>>
>> Hey, which tree did you apply it to?
>
>https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
>
>/fuad
>
>>
>>
>> Thanks!
>
Thanks fuad.
May I ask if this would be put onto ACK?
Since this affects pixel devices.
(E.g, my pixel 7....)
Thanks!
^ permalink raw reply
* Re: [PATCH v1 1/1] i2c: nomadik: Use generic definitions for bus frequencies
From: Andi Shyti @ 2026-06-23 15:10 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-arm-kernel, linux-i2c, linux-kernel, Linus Walleij
In-Reply-To: <20260618141730.3243303-1-andriy.shevchenko@linux.intel.com>
Hi Andy,
On Thu, Jun 18, 2026 at 04:17:30PM +0200, Andy Shevchenko wrote:
> Since we have generic definitions for bus frequencies, let's use them.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
I merged all this seriesin i2c/i2c.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH] iio: stm32-dfsdm: Treat flags as booleans
From: Jonathan Cameron @ 2026-06-23 15:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Olivier MOYSAN, Rob Herring (Arm), David Lechner, Nuno Sá,
Andy Shevchenko, Maxime Coquelin, Alexandre Torgue, linux-iio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <ajpX3E2zHYh2e8FG@ashevche-desk.local>
On Tue, 23 Jun 2026 12:54:36 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Jun 23, 2026 at 11:43:49AM +0200, Olivier MOYSAN wrote:
> > On 6/21/26 16:10, Jonathan Cameron wrote:
> > > On Sat, 13 Jun 2026 16:39:16 +0300
> > > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > > > On Fri, Jun 12, 2026 at 04:51:50PM -0500, Rob Herring (Arm) wrote:
>
> ...
>
> > > > > - ret = of_property_read_u32_index(indio_dev->dev.of_node,
> > > > > - "st,adc-alt-channel", chan_idx,
> > > > > - &df_ch->alt_si);
> > > >
> > > > > + df_ch->alt_si = of_property_present(indio_dev->dev.of_node,
> > > >
> > > > I believe it still has another (serious?) issue. We usually don't use indio_dev
> > > > for device properties. It's not a device that is described in DT.
> > > > It seems the only driver in IIO that does that. Note, I haven't conducted any
> > > > deeper research, it might be (however I'm quite in doubt) that this is correct
> > > > use and one device registers a few indio_dev:s.
> > >
> > > It is curious. The registration sequence in this driver is complex, but I'm not
> > > seeing anything that sets the fwnode for the struct iio_dev->dev before calling
> > > the init() callbacks that end up in this code. It is set later by iio_device_register()
> > > (iirc that has something to do with consumers turning up later).
> > >
> > > St folk could you take a look at this and see what we are missing
> > > if it does currently work?
> > >
> > > For now I'll apply this patch but might need to drop it if a fix clashes
> > > with it.
> >
> > I confirm that the current legacy path is functional
> > (With the st,adc-alt-channel property fix applied)
>
> Yeah, it's here
> https://elixir.bootlin.com/linux/v7.1.1/source/drivers/iio/adc/stm32-dfsdm-adc.c#L1772
> and should gone. Basically one wants to replace all these to use device and
> fwnode propery APIs and proper device node, without that hack.
If we 'were' going to keep this it should have been using the helper
to set that. I thought all those had been cleaned up so didn't check
for it being directly written :( Obviously this comment is irrelevant
given the code is going away!
Jonathan
>
> > It currently works because the driver initializes np from dev->of_node in
> > probe, and that value is then used in init callbacks.
> >
> > I agree that this approach is not robust, as it depends on initialization
> > sequencing and on using an IIO object that is not the DT owner object. I
> > will prepare a patch to use the DT device directly as the single source for
> > DT properties.
> >
> > I also suggest keeping a fallback path for st,adc-alt-channel so we do not
> > break legacy DTs that have not yet migrated to the new binding.
> > I prepare this also.
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Fuad Tabba @ 2026-06-23 15:03 UTC (permalink / raw)
To: Bradley Morgan
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <CE64C9AC-32D5-495E-B713-552921468FB9@grrlz.net>
On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
>
> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> >> Protected guest faults charge long term pins to the VM's mm. Teardown
> >> can run later from file release, where current->mm may be unrelated.
> >>
> >> Drop the charge from kvm->mm instead.
> >>
> >>
> >
> >Applied to fixes, thanks!
> >
> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> > commit: d098bb75d14fde2f12155f1a95ec0168160867ce
> >
> >Cheers,
> >
> > M.
> >
>
>
> Hey, which tree did you apply it to?
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
/fuad
>
>
> Thanks!
^ permalink raw reply
* Re: [PATCH] ARM: imx: Drop obsolte stuff from common.h
From: Frank Li @ 2026-06-23 14:42 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel, imx
In-Reply-To: <ajqZIBDVccYSGoIY@monoceros>
On Tue, Jun 23, 2026 at 04:33:50PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On Tue, Jun 23, 2026 at 08:07:37AM -0500, Frank Li wrote:
> > On Tue, Jun 23, 2026 at 12:45:57PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > i.MX21 (and thus imx21_init_early()) is gone since v5.10-rc1 (commit
> > > 4b563a066611 ("ARM: imx: Remove imx21 support")).
> > >
> > > The init_irq() functions are gone since v5.12-rc5 (commit e2c1b0ff38c9
> > > ("ARM: imx: avic: Convert to using IRQCHIP_DECLARE")).
> > >
> > > And mxc_device_init() was removed for v5.10-rc1 (in commit 8485adf17a15
> > > ("ARM: imx: Remove imx device directory")).
> > >
> > > The last user of imx1_reset_init() is gone since v4.9-rc1 (commit
> > > e1291cffcc50 ("ARM: i.MX: Remove i.MX1 non-DT support")).
> > >
> > > Drop declaration of enum mxc_cpu_pwr_mode, the actual definition follows
> > > later in common.h without a usage in-between.
> > >
> > > All users of of_device_id also include <linux/of.h>,
> > > <linux/of_address.h> or <linux/of_platform.h> which is enough to not
> > > need the forward declaration.
> > >
> > > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> > > ---
> > > [...]
> > > void mx31_map_io(void);
> > > void mx35_map_io(void);
> > > -void imx21_init_early(void);
> > > void imx31_init_early(void);
> > > void imx35_init_early(void);
> > > -void mx31_init_irq(void);
> > > -void mx35_init_irq(void);
> >
> > which commit remove above two functions?
>
> These are covered by:
>
> > > The init_irq() functions are gone since v5.12-rc5 (commit e2c1b0ff38c9
> > > ("ARM: imx: avic: Convert to using IRQCHIP_DECLARE")).
Thanks
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Bradley Morgan @ 2026-06-23 15:01 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <178222278590.523236.18181071715501850418.b4-ty@kernel.org>
On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
>> Protected guest faults charge long term pins to the VM's mm. Teardown
>> can run later from file release, where current->mm may be unrelated.
>>
>> Drop the charge from kvm->mm instead.
>>
>>
>
>Applied to fixes, thanks!
>
>[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> commit: d098bb75d14fde2f12155f1a95ec0168160867ce
>
>Cheers,
>
> M.
>
Hey, which tree did you apply it to?
Thanks!
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frank Li @ 2026-06-23 14:36 UTC (permalink / raw)
To: Peng Fan
Cc: Frieder Schrempf, Krzysztof Kozlowski, Frieder Schrempf,
Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <ajoJFt6c1cKELlH6@shlinux89>
On Tue, Jun 23, 2026 at 12:18:30PM +0800, Peng Fan wrote:
> On Mon, Jun 22, 2026 at 09:14:43AM -0500, Frank Li wrote:
> >On Wed, Jun 17, 2026 at 01:36:30PM +0200, Frieder Schrempf wrote:
> >> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
> >> > On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
> >> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> >>
> >> >> Some SoCs like the i.MX9 family allow full access to the fuses only
> >> >> through the secure enclave firmware API. Add a property to reference
> >> >> the secure enclave node and let the driver use the API.
> >> >>
> >> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> >> ---
> >> >> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
> >> >> 1 file changed, 4 insertions(+)
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> >> index a8076d0e2737..14a6429f4a4c 100644
> >> >> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> >> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> >> @@ -53,6 +53,10 @@ properties:
> >> >> reg:
> >> >> maxItems: 1
> >> >>
> >> >> + secure-enclave:
> >> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> >> + description: A phandle to the secure enclave node
> >> >
> >> > Two things here:
> >> > 1. Here you describe what for is that phandle, how it is used by the
> >> > hardware. Currently the description repeats the property name and type,
> >> > so not much useful.
> >>
> >> Ok, agree.
> >>
> >> >
> >> > 2. If you access OTP via firmware, then this is completely different
> >> > interface than MMIO, thus:
> >> > A. reg is not appropriate
> >> > B. Device is very different thus it has different compatible and I even
> >> > claim should be in different binding. Devices having completely
> >> > different SW interface should not be in the same binding, at least
> >> > usually.
> >> >
> >> > If any of above is not accurate, then your commit msg should answer why
> >> > and give some background.
> >>
> >> Thanks for the feedback!
> >>
> >> The driver currently uses the limited MMIO (FSB) interface to access the
> >> OTPs. The intention is to support the firmware interface alongside the
> >> MMIO interface so the driver can pick the interface that is available
> >> (firmware might not be loaded) and fallback to MMIO.
> >
> >Does ELE and MMIO access the same bank of fuse? If access the same bank,
>
> Some fuse banks are only accessible through ELE firmware. Some fuse banks
> are accessible using MMIO. In theory, ELE firmware are able to access all
> fuse banks.
So use two driver for it, one use current MMIO ot access part of fuse box.
use ELE access the left part, which MMIO can't access.
MMIO should be simple and quick than go through ELE.
Frank
>
> Regards
> Peng
>
> >why not always use MMIO. Any beneafit from ELE firmware?
>
> >
> >Frank
> >>
> >> Following your argument would mean a driver deciding by itself which
> >> interface to use at runtime is not something we want to have in general,
> >> right?
> >>
> >> In turn this would mean we need two drivers, or at least two
> >> compatibles/bindings for something that is effectively the same hardware.
> >>
> >> Actually, my first RFC approach [1] was to create a separate driver. But
> >> in the end it seemed very weird to have two drivers and two DT nodes for
> >> the same hardware block. Also I have no idea what happens if both
> >> interfaces are used at the same time.
> >>
> >> The other idea from back then was to replace the MMIO (FSB) interface
> >> with ELE, but this would mean that we rely on the proprietary ELE
> >> firmware to be available for simple things like reading a MAC address,
> >> which is not desirable either, I guess.
> >>
> >> In which direction should I move on with this?
> >>
> >> [1]
> >> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250416142715.1042363-1-frieder@fris.de/
> >>
^ 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