* [PATCH] media: cec: stm32: return an error when log-address wait times out
From: Pengpeng Hou @ 2026-06-24 14:40 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Maxime Coquelin,
Alexandre Torgue
Cc: Pengpeng Hou, linux-media, linux-stm32, linux-arm-kernel,
linux-kernel
stm32_cec_adap_log_addr() waits for TXSOM to clear before disabling CEC
and updating the logical address registers. The wait result is ignored,
so a timeout can still be reported as a successful logical address
update.
Return the polling error before touching the address registers. Compute
the address mask only for valid logical addresses so the invalid-address
path does not evaluate a shift based on CEC_LOG_ADDR_INVALID.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/media/cec/platform/stm32/stm32-cec.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/media/cec/platform/stm32/stm32-cec.c b/drivers/media/cec/platform/stm32/stm32-cec.c
index 1ec0cece0..82709b5ec 100644
--- a/drivers/media/cec/platform/stm32/stm32-cec.c
+++ b/drivers/media/cec/platform/stm32/stm32-cec.c
@@ -193,18 +193,24 @@ static int stm32_cec_adap_enable(struct cec_adapter *adap, bool enable)
static int stm32_cec_adap_log_addr(struct cec_adapter *adap, u8 logical_addr)
{
struct stm32_cec *cec = adap->priv;
- u32 oar = (1 << logical_addr) << 16;
u32 val;
+ int ret;
/* Poll every 100µs the register CEC_CR to wait end of transmission */
- regmap_read_poll_timeout(cec->regmap, CEC_CR, val, !(val & TXSOM),
- 100, CEC_XFER_TIMEOUT_MS * 1000);
+ ret = regmap_read_poll_timeout(cec->regmap, CEC_CR, val, !(val & TXSOM),
+ 100, CEC_XFER_TIMEOUT_MS * 1000);
+ if (ret)
+ return ret;
+
regmap_update_bits(cec->regmap, CEC_CR, CECEN, 0);
- if (logical_addr == CEC_LOG_ADDR_INVALID)
- regmap_update_bits(cec->regmap, CEC_CFGR, OAR, 0);
- else
+ if (logical_addr == CEC_LOG_ADDR_INVALID) {
+ regmap_update_bits(cec->regmap, CEC_CFGR, OAR, 0);
+ } else {
+ u32 oar = BIT(logical_addr) << 16;
+
regmap_update_bits(cec->regmap, CEC_CFGR, oar, oar);
+ }
regmap_update_bits(cec->regmap, CEC_CR, CECEN, CECEN);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v15 07/11] arm64: syscall: Introduce syscall_exit_to_user_mode_work()
From: Ada Couprie Diaz @ 2026-06-24 14:37 UTC (permalink / raw)
To: Jinjie Ruan, mark.rutland
Cc: peterz, catalin.marinas, ldv, song, will, kees, thuth,
ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan, broonie,
luto, linux-arm-kernel, wad, yeoreum.yun, oleg, linux-kernel,
james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-8-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor the system call exit path to align with the generic entry
> framework. This consolidates thread flag checking, rseq handling, and
> syscall tracing into a structure that mirrors the generic
> syscall_exit_to_user_mode_work() implementation.
>
> [Rationale]
> The generic entry code employs a hierarchical approach for
> syscall exit work:
>
> 1. syscall_exit_to_user_mode_work(): The entry point that handles
> rseq and checks if further exit work (tracing/audit) is required.
>
> 2. syscall_exit_work(): Performs the actual tracing, auditing, and
> ptrace reporting.
>
> [Changes]
> - Rename and Encapsulate: Rename syscall_trace_exit() to
> syscall_exit_work() and make it static, as it is now an internal
> helper for the exit path.
>
> - New Entry Point: Implement syscall_exit_to_user_mode_work() to
> replace the manual flag-reading logic in el0_svc_common(). This
> function now encapsulates the rseq_syscall() call and the
> conditional execution of syscall_exit_work().
>
> - Simplify el0_svc_common(): Remove the complex conditional checks
> for tracing and CONFIG_DEBUG_RSEQ at the end of the syscall path,
> delegating this responsibility to the new helper.
It is indeed simpler, however to me there are two changes to the behaviour,
which are not called out (apologies if I missed some prior discussion
when I looked for some) :
1. As pointed by the removed comment, in mainline we *always* trace on exit
if we traced on entry. This is why there are two
`has_syscall_work()` checks
on exit, with a re-read of the flags after syscall execution in between.
This change only checks once on exit after updating the flags, so if
there was work on entry but the flags got cleared, it *won't* trace
on exit.
Is this desired ? Can this change of behaviour have an impact ?
> - Helper Migration: Move has_syscall_work() to asm/syscall.h
> to allow its reuse across ptrace.c and syscall.c.
>
> - Clean up RSEQ: Remove the explicit IS_ENABLED(CONFIG_DEBUG_RSEQ)
> check in the caller, as rseq_syscall() is already a no-op when the
> config is disabled.
2. `rseq_syscall()` is indeed a no-op, but removing the explicit check here
does change the behaviour : in mainline we *always* trace on exit if
`CONFIG_DEBUG_RSEQ` is enabled, bypassing the `has_syscall_work()`
check.
This change does not bypass the `has_syscall_work()` check if
`CONFIG_DEBUG_RSEQ` is enabled, so there might be a change of behaviour.
Same questions as above : is this change desired ? Can it have an
impact ?
I understand that the change is to align with the generic entry, but it
seems
like this could have an impact that I do not really understand, so I prefer
asking !
Apart from the above everything looks OK to me, but I'd like
some confirmation that the change of behaviours either do not exist or
are OK !
Thanks,
Ada
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> v15
> - Make syscall_exit_to_user_mode_work() __always_inline to keep
> the fast-path performance as Sashiko pointed out.
> ---
> arch/arm64/include/asm/syscall.h | 18 +++++++++++++++++-
> arch/arm64/kernel/ptrace.c | 5 +----
> arch/arm64/kernel/syscall.c | 20 +-------------------
> 3 files changed, 19 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
> index 30b203ef156b..b331e09b937f 100644
> --- a/arch/arm64/include/asm/syscall.h
> +++ b/arch/arm64/include/asm/syscall.h
> @@ -8,6 +8,7 @@
> #include <uapi/linux/audit.h>
> #include <linux/compat.h>
> #include <linux/err.h>
> +#include <linux/rseq.h>
>
> typedef long (*syscall_fn_t)(const struct pt_regs *regs);
>
> @@ -121,6 +122,21 @@ static inline int syscall_get_arch(struct task_struct *task)
> }
>
> int syscall_trace_enter(struct pt_regs *regs, unsigned long flags);
> -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags);
> +void syscall_exit_work(struct pt_regs *regs, unsigned long flags);
> +
> +static inline bool has_syscall_work(unsigned long flags)
> +{
> + return unlikely(flags & _TIF_SYSCALL_WORK);
> +}
> +
> +static __always_inline void syscall_exit_to_user_mode_work(struct pt_regs *regs)
> +{
> + unsigned long flags = read_thread_flags();
^-- This only reflects the post-syscall flags
> +
> + rseq_syscall(regs);
> +
> + if (has_syscall_work(flags) || flags & _TIF_SINGLESTEP)
> + syscall_exit_work(regs, flags);
> +}
>
> #endif /* __ASM_SYSCALL_H */
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 15a45eeb56da..256aa20377e1 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -28,7 +28,6 @@
> #include <linux/hw_breakpoint.h>
> #include <linux/regset.h>
> #include <linux/elf.h>
> -#include <linux/rseq.h>
>
> #include <asm/compat.h>
> #include <asm/cpufeature.h>
> @@ -2454,10 +2453,8 @@ int syscall_trace_enter(struct pt_regs *regs, unsigned long flags)
> return syscall;
> }
>
> -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags)
> +void syscall_exit_work(struct pt_regs *regs, unsigned long flags)
> {
> - rseq_syscall(regs);
> -
> audit_syscall_exit(regs);
^-- This was always called if entry had work or CONFIG_DEBUG_RSEQ was enabled,
which is not the case anymore (same for the rest of the function)
>
> if (flags & _TIF_SYSCALL_TRACEPOINT)
> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> index f6f87b042995..dac7bcc4bbdf 100644
> --- a/arch/arm64/kernel/syscall.c
> +++ b/arch/arm64/kernel/syscall.c
> @@ -54,11 +54,6 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
> syscall_set_return_value(current, regs, 0, ret);
> }
>
> -static inline bool has_syscall_work(unsigned long flags)
> -{
> - return unlikely(flags & _TIF_SYSCALL_WORK);
> -}
> -
> static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> const syscall_fn_t syscall_table[])
> {
> @@ -120,21 +115,8 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> }
>
> invoke_syscall(regs, scno, sc_nr, syscall_table);
> -
> - /*
> - * The tracing status may have changed under our feet, so we have to
> - * check again. However, if we were tracing entry, then we always trace
> - * exit regardless, as the old entry assembly did.
> - */
> - if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) {
^-- We always traced exit if CONFIG_DEBUG_RSEQ is enabled
^-- `flags` is unchanged since entry, and exit was always traced if there was work.
> - flags = read_thread_flags();
> - if (!has_syscall_work(flags) && !(flags & _TIF_SINGLESTEP))
> - return;
> - }
> -
> trace_exit:
> - flags = read_thread_flags();
> - syscall_trace_exit(regs, flags);
> + syscall_exit_to_user_mode_work(regs);
> }
>
> void do_el0_svc(struct pt_regs *regs)
^ permalink raw reply
* [PATCH] mailbox: imx: return TXDB_V2 timeout errors
From: Pengpeng Hou @ 2026-06-24 14:37 UTC (permalink / raw)
To: Jassi Brar, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Pengpeng Hou, linux-kernel, imx, linux-arm-kernel
imx_mu_generic_tx() retries TXDB_V2 doorbell sends until the GIR bit
clears, but falls through to the common success return even when every
readl_poll_timeout() attempt failed.
Return the final timeout error after the retry loop so mailbox clients
can observe a failed doorbell send instead of treating it as successful.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mailbox/imx-mailbox.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 246a9a9e3..86a8a590b 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -253,6 +253,8 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
cp->type, ++count);
}
}
+ if (ret)
+ return ret;
break;
default:
dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [RFC PATCH 6/6] arm64: mm: support PMD page coalescing in the linear map
From: Adrian Barnaś @ 2026-06-24 14:32 UTC (permalink / raw)
To: Ryan Roberts
Cc: linux-arm-kernel, linux-mm, Catalin Marinas, Will Deacon,
David Hildenbrand, Mike Rapoport (Microsoft), Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman
In-Reply-To: <799181c3-a1a1-4de7-bc6a-576d3282efb0@arm.com>
On Fri, Jun 19, 2026 at 02:40:40PM +0100, Ryan Roberts wrote:
>On 11/06/2026 14:01, Adrian Barnaś wrote:
>> Implement PMD block coalescing to merge fragmented linear mapping regions
>> back into huge pages when restoring the read-only attribute.
>>
>> When memory allocated with VM_ALLOW_HUGE_VMAP (such as for the execmem
>> ROX cache) has its permissions modified, the PMD block mapping is split
>> into individual PTEs. Without this change, when that memory have its RO
>> attribute subsequently cleared and set the mapping remains permanently
>> fragmented into 4K pages.
>
>I'd like to make sure I understand this correctly: So the execmem ROX cache is
>allocated using vmalloc_huge such that all it's backing memory are PMD-sized
>pages. It is initially poisoned with a faulting instruction and marked ROX. When
>a module is loaded, it's text is copied into a portion of the ROX cache and
>executed from there? To do that, the required number of (4K) pages are allocated
>from ROX cache, and the permissions are changed on that sub-region to RW,
>meaning we have to split the mapping from a PMD to (cont)PTEs in both vmalloc
>space and in the linear map. After the text is copied, the sub-region is
>switched back to ROX. But without that change, the 2M region is now mapped by
>(cont)PTEs for all of time?
That is correct.
>
>>
>> Signed-off-by: Adrian Barnaś <abarnas@google.com>
>> ---
>> arch/arm64/include/asm/mmu.h | 1 +
>> arch/arm64/mm/mmu.c | 95 ++++++++++++++++++++++++++++++++++++
>> arch/arm64/mm/pageattr.c | 7 +++
>> 3 files changed, 103 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
>> index 137a173df1ff..19158bacb2df 100644
>> --- a/arch/arm64/include/asm/mmu.h
>> +++ b/arch/arm64/include/asm/mmu.h
>> @@ -80,6 +80,7 @@ extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
>> extern void mark_linear_text_alias_ro(void);
>> extern int split_kernel_leaf_mapping(unsigned long start, unsigned long end);
>> extern void linear_map_maybe_split_to_ptes(void);
>> +void try_collapse_kernel_pmd(unsigned long addr);
>>
>> /*
>> * This check is triggered during the early boot before the cpufeature
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a6a00accf4f9..d74226fa1c9b 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -769,6 +769,101 @@ static inline bool force_pte_mapping(void)
>>
>> static DEFINE_MUTEX(pgtable_split_lock);
>>
>> +static inline bool __pte_can_be_collapsed(pte_t pte, unsigned long pfn, pgprot_t prot)
>> +{
>> + if (!pte_valid(pte))
>> + return false;
>> + if (pte_pfn(pte) != pfn)
>> + return false;
>> + if ((pgprot_val(pte_pgprot(pte)) & ~PTE_CONT) != pgprot_val(prot))
>
>Do we want to permit differing values for access and dirty? We do for user
>space, but I think for kernel, those bits are always set? In which case, what
>you're doing is correct.
>
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static void __try_collapse_pmd(pmd_t *pmdp, pmd_t pmd, unsigned long addr)
>> +{
>> + pte_t *ptep;
>> + pte_t first_pte;
>> + unsigned long pfn;
>> + pgprot_t prot;
>> + int i;
>> +
>> + ptep = (pte_t *)pmd_page_vaddr(pmd);
>> + first_pte = __ptep_get(ptep);
>> +
>> + if (!pte_valid(first_pte))
>> + return;
>> +
>> + prot = pte_pgprot(first_pte);
>> + prot = __pgprot(pgprot_val(prot) & ~PTE_CONT);
>> + pfn = pte_pfn(first_pte);
>> +
>> + if (!IS_ALIGNED(pfn, PMD_SIZE >> PAGE_SHIFT))
>> + return;
>> +
>> + for (i = 1; i < PTRS_PER_PTE; i++) {
>> + if (!__pte_can_be_collapsed(__ptep_get(ptep + i), pfn + i, prot))
>> + return;
>> + }
>> +
>> + set_pmd(pmdp, pmd_mkhuge(pfn_pmd(pfn, prot)));
>> +
>> + __flush_tlb_kernel_pgtable(addr);
>> +
>
>nit: suggest adding the same comment that other sites has, since this is not
>obvious:
>
>/* See comment in pud_free_pmd_page for static key logic */
>
>> + if (static_branch_unlikely(&arm64_ptdump_lock_key)) {
>> + mmap_read_lock(&init_mm);
>> + mmap_read_unlock(&init_mm);
>> + }
>> +
>> + pte_free_kernel(NULL, ptep);
>
>Ooh, fun. Per my comments below we definitely have opportunity for racy pte
>table accesses (beyond ptdump). I _think_ if you fix that then this will be safe.
>
>> +}
>> +
>> +void try_collapse_kernel_pmd(unsigned long addr)
>> +{
>> + pgd_t *pgdp;
>> + p4d_t *p4dp;
>> + pud_t *pudp;
>> + pmd_t *pmdp;
>> + pmd_t pmd;
>> +
>> + /*
>> + * collapse_pmd expects exact address of block to be collapsed
>> + */
>> + if (WARN_ON(ALIGN_DOWN(addr, PMD_SIZE) != addr))
>> + return;
>> +
>> + mutex_lock(&pgtable_split_lock);
>
>I don't think this is safe in general. Let's say we have a 2M region split into
>512 x 4K PTEs. It's possible that the first 1M is one object and the second 1M
>is another object. Different CPUs could set_memory_*() on those 2 objects
>concurrently. If one of them then calls this function, we could end up
>collapsing the whole 2M while the other is trying to modify the PTEs and they
>will race.
>
>Note that splitting _is_ safe (and protected by this lock) because you'd have 2
>objects backed by the same PMD, so they would both have to split before
>modifying the PTEs.
>
>I think you'd need to ensure mutual exclusion at a higher level if doing this;
>probably execmem is the place that can ensure that no objects within a 2M region
>are racily trying to modify their permissions?
>
>> +
>> + pgdp = pgd_offset_k(addr);
>> + if (pgd_none(READ_ONCE(*pgdp)))
>
>nit: use the getters (e.g. pXdp_get()) instead of READ_ONCE().
>
>> + goto out;
>> +
>> + p4dp = p4d_offset(pgdp, addr);
>> + if (p4d_none(READ_ONCE(*p4dp)))
>> + goto out;
>> +
>> + pudp = pud_offset(p4dp, addr);
>> + if (pud_none(READ_ONCE(*pudp)))
>> + goto out;
>> +
>> + if (pud_leaf(READ_ONCE(*pudp)))
>> + goto out;
>> +
>> + pmdp = pmd_offset(pudp, addr);
>> + pmd = pmdp_get(pmdp);
>> +
>> + if (!pmd_table(pmd))
>> + goto out;
>> +
>> + lazy_mmu_mode_enable();
>> + __try_collapse_pmd(pmdp, pmd, addr);
>> + lazy_mmu_mode_disable();
>> +
>> +out:
>> + mutex_unlock(&pgtable_split_lock);
>> +}
>> +
>> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
>> {
>> int ret;
>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>> index eaefdf90b0d5..11e0b60264c3 100644
>> --- a/arch/arm64/mm/pageattr.c
>> +++ b/arch/arm64/mm/pageattr.c
>> @@ -200,6 +200,13 @@ static int change_memory_common(unsigned long addr, int numpages,
>> if (ret)
>> return ret;
>> }
>
>The loop here in the unchanged code, calls __change_memory_common() for each
>PAGE_SIZE page in the linear alias. Perhaps it should be area->page_order aware?
>That way, if we are changing the permissions of the whole 2M chunk of vmalloc
>space and it's backed by a 2M page, then we won't split the mapping to PTEs in
>the linear map. Similarly, if we are changing permissions on a sub-region of the
>2M area, we might be able to split only as far as contpte and still have some
>performance benefit?
>
This is out of scope of execmem (as you noted we are mostly changing permision
for only a part of the block) but your sugestion seems to be valid for other
cases.
>> + /*
>> + * When setting a read-only flag on the linear region, the memory
>> + * may have been backed by a PMD before being split. Try to
>> + * collapse it back into a PMD to restore huge page performance.
>> + */
>> + if (pgprot_val(set_mask) == PTE_RDONLY && area->flags & VM_ALLOW_HUGE_VMAP)
>> + try_collapse_kernel_pmd((u64)page_address(area->pages[0]));
>
>try_collapse_kernel_pmd() requires a PMD-aligned address. VM_ALLOW_HUGE_VMAP
>doesn't guarrantee that - it only says that it's _allowed_ to be huge (and 64K
>would still be huge). vmalloc may have failed to allocate a PMD-sized page and
>reverted to something smaller (64K contpte or 4K). You need to look at
>area->page_order, I think.
>
Agree.
>You're only calling this for the linear alias. Don't you want to call it for the
>vmalloc range too? I assume the module text executes using the vmalloc address
>so you'd want it mapped by a single PMD for best performance?
>
I think it is a good idea to have them both (linear alias and vmalloc area)
mapped as PMD.
>But in general, I don't really like the idea of special-casing a collapse to pmd
>here for just execmem. I think we should either investigate a general purpose
>collapse mechanism or execmem should have extra hooks added to request specific
>collapse.>
>Thanks,
>Ryan
>
>
>> }
>>
>> /*
>
I will rethink this based on your suggestion and try to properly fix the
concurrency issues.
I am also wondering if we should avoid splitting linear aliases altogether.
I think I understand why it was done originally (to restrict writing through
linear mapping aliases for read-only vmalloc areas). However, it is not
necessary to make them writable when the vmalloc area is writable. Maybe
we should create a special case for execmem to prevent this. WDYT?
Thank you for the review,
Adrian
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 14:25 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Yuanfang Zhang,
Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 05:49:26PM +0800, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
> Add the arm,primecell-periphid property to bypass the AMBA bus
> check and resolve the probe issue.
tnoc.c registers both an AMBA driver and a platform driver. Shouldn't it
be registered as a platform device instead?
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Michal Simek @ 2026-06-24 14:21 UTC (permalink / raw)
To: Mathieu Poirier
Cc: tanmay.shah, andersson, linux-arm-kernel, linux-kernel,
linux-remoteproc
In-Reply-To: <CANLsYkyChucfAY1wKvxAt9-tCX=2B5L9=4bbBA6XvnpBnLZD5Q@mail.gmail.com>
On 6/24/26 16:02, Mathieu Poirier wrote:
> On Wed, 24 Jun 2026 at 00:12, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> 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>
>>
>
> Michal - do you prefer that I pick this patch on the remoteproc side?
yes please.
Thanks,
Michal
^ permalink raw reply
* Re: (subset) [PATCH v7 00/30] Add HDMI 2.0 support to DW HDMI QP TX
From: Luca Ceresoli @ 2026-06-24 14:08 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Sandy Huang,
Heiko Stübner, Andy Yan, Daniel Stone, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance,
Cristian Ciocaltea
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
Dmitry Baryshkov, Diederik de Haas, Maud Spierings
In-Reply-To: <20260602-dw-hdmi-qp-scramb-v7-0-445eb54ee1ed@collabora.com>
On Tue, 02 Jun 2026 01:44:00 +0300, Cristian Ciocaltea wrote:
> Enable HDMI 2.0 display modes (e.g. 4K@60Hz) on the Synopsys DW HDMI QP
> TX controller, as found in Rockchip RK3576 & RK3588 SoCs, by adding SCDC
> management for high TMDS clock ratio and scrambling.
>
> Since SCDC state is lost on sink disconnects, the bridge driver needs to
> trigger a CRTC reset during connector detection. To support this, the
> series introduces the connector and bridge scrambling infrastructure
> (patches 1-8), wires it up through the bridge connector layer with an
> atomic-aware detect_ctx hook (patches 9-11), then implements the SCDC
> scrambling feature in the DW HDMI QP bridge driver (patches 12-15).
>
> [...]
Applied, thanks!
[01/30] drm/fb-helper: Remove unused local variable in hotplug_event()
commit: cdeb2ccd993ed8647adbbda2c3b103aa717fd6f7
Best regards,
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* mm: opaque hardware page-table entry handles
From: Usama Anjum @ 2026-06-24 14:09 UTC (permalink / raw)
To: Andrew Morton, Lorenzo Stoakes, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Ryan Roberts, Anshuman Khandual,
Catalin Marinas, Will Deacon, Samuel Holland
Cc: usama.anjum, linux-mm, linux-arm-kernel, linux-kernel
Hi all,
This is a direction-check with the wider community before spending time on the
development. This picks up the idea that was raised and broadly agreed in the
earlier thread (Ryan Roberts, Lorenzo Stoakes, David Hildenbrand) [1].
The problem
-----------
Core MM code reaches page-table entries by raw pointer dereference (pte_t *,
pmd_t *, *pud, ...) in places, implicitly assuming a single, uniform
representation. Sprinkling getters wouldn't solve the problem entirely. The
problem is one level up: the *pointer type* itself is overloaded. At each level
there are really three distinct things:
1. a page-table entry value (pte_t, pmd_t, ...)
2. a pointer to an entry value, e.g. a pXX_t on the stack
3. a pointer to a live entry in the hardware page table
Today (2) and (3) share the same type - pte_t *, pmd_t *, and so on. Nothing
distinguishes a pointer into a live table from a pointer to a stack copy.
A pointer to an on-stack entry value and a pointer to a live hardware entry have
the same type, so the compiler cannot distinguish them. Passing the stack
pointer to an arch helper that expects a hardware-entry pointer compiles fine,
but is wrong - a bug class the type system makes invisible. It also blocks
evolution: an arch helper may need to read beyond the addressed entry (e.g.
adjacent or contiguous entries), which only makes sense for a real page-table
pointer, not a stack copy.
The idea
--------
Give (3) its own opaque type that cannot be dereferenced:
/* opaque handle to a HW page-table entry; not dereferenceable */
typedef struct {
pte_t *ptr;
} hw_ptep;
With this:
- a stack value can no longer masquerade as a hardware table entry,
- a hardware handle can no longer be raw-dereferenced,
- cases that genuinely operate on a value can be refactored to pass the value
and let the caller, which knows whether it holds a handle or a stack copy,
read it once.
The overload becomes a compile-time type error instead of a silent runtime bug,
and converting the tree forces every such site to be made explicit. This gives
us a framework where the architecture can completely virtualize the pgtable if
it likes; and the compiler can enforce that higher level code can't accidentally
work around it.
It is opt-in by architectures and incremental. The generic definition is
just an alias, so arches that do not care build unchanged:
typedef pte_t *hw_ptep;
An arch flips to the strong struct type when it is ready, and only then does
it get the stronger checking. This lets the conversion land gradually.
Beyond fixing the latent bug class, this abstraction is an enabler for upcoming
features that need tighter control over how page tables are accessed and
manipulated.
Getter flavours
---------------
While converting, it is useful to have two accessor flavours at each level:
- pXXp_get(hw_ptep) plain C dereference (compiler may optimize)
- pXXp_get_once(hw_ptep) single-copy-atomic, not torn, elided or
duplicated by the compiler
Keeping them distinct simplifies the conversion and avoids re-introducing the
class of lockless-read bugs seen on 32-bit.
Example conversion
------------------
Most of the conversion is mechanical.
-static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pte, unsigned int nr)
+static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
+ hw_ptep ptep, pte_t pte, unsigned int nr)
{
page_table_check_ptes_set(mm, addr, ptep, pte, nr);
for (;;) {
set_pte(ptep, pte);
if (--nr == 0)
break;
- ptep++;
+ ptep = hw_pte_next(ptep);
pte = pte_next_pfn(pte);
}
}
The bulk of work is this kind of rote substitution. The genuine work is the
handful of sites that turn out to be operating on a stack copy rather than a
live entry - those are exactly the ones the new type forces us to surface and
fix.
Estimated churn:
----------------
Half way through the prototyping converting only PTE and PMD levels:
77 files changed, +1801 / -1425
~57 files reference the new types
So the line count will grow once PUD/P4D/PGD and the remaining call sites are
converted; expect meaningfully more churn than the numbers above.
Introduce the type as an alias, convert one helper family per patch, and flip
an arch to the strong type last - with non-opted arches building unchanged at
every step.
Open questions
--------------
- Is the type-safety + future-feature enablement worth the churn?
- Naming: hw_ptep/hw_pmdp vs something else?
- Should all five levels be converted before merging anything, or is a staged
PTE-and-PMD then landing others acceptable?
- Do we want the two getter flavours (pXXp_get / pXXp_get_once) at every
level?
[1] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 13:48 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f0634a64-1141-4ff9-9033-825e3c75d28d@oss.qualcomm.com>
On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
> On 6/24/26 11:49 AM, Jie Gan wrote:
>> The AMBA bus attempts to read the CID/PID of a device before invoking
>> its probe function if the arm,primecell-periphid property is absent.
>> This causes a deferred probe issue for the TraceNoC device, as the
>> CID/PID cannot be read from the periphid register.
>
> Why does it probe defer?
>
For an AMBA device, the periphid is mandatory for probing. In the
amba_match function, AMBA attempts to read the periphid from the CID/PID
registers if the arm,primecell-periphid property is absent in the device
tree. If this read fails, it returns -EPROBE_DEFER, and the probe
ultimately fails.
Most AMBA devices expose valid CID/PID registers, so specifying
arm,primecell-periphid in the device tree is usually unnecessary.
However, for the TraceNoC device in this case, AMBA cannot reliably read
the periphid from the corresponding registers.
> And is this required for all TNOC devices?
So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
platforms, and all exhibit probe failures due to the same root cause.
I prefer to fix it on Kaanapali first.
Thanks,
Jie
>
> Konrad
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Mathieu Poirier @ 2026-06-24 14:02 UTC (permalink / raw)
To: Michal Simek
Cc: tanmay.shah, andersson, linux-arm-kernel, linux-kernel,
linux-remoteproc
In-Reply-To: <59d9a4c9-1f12-4de9-a0d6-613d2f5e9852@amd.com>
On Wed, 24 Jun 2026 at 00:12, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> 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>
>
Michal - do you prefer that I pick this patch on the remoteproc side?
> Thanks,
> Michal
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The PCIe PHY node references mipi_pcie_analog_dphy via its phys property.
Enable this analog PHY node to make PCIe functionally viable.
Fixes: 9715b01da6cf ("arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 7ba249cc3d56..4f13e2b041e1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -431,6 +431,10 @@ gpio_speaker: gpio-controller@1f {
};
};
+&mipi_pcie_analog_dphy {
+ status = "okay";
+};
+
&pdm {
pinctrl-0 = <&pdm_dclk_a14_pins>, <&pdm_din0_pins>,
<&pdm_din1_pins>, <&pdm_din2_pins>, <&pdm_din3_pins>;
--
2.54.0
^ permalink raw reply related
* Re: [RFC PATCH 3/6] arm64: mm: fix restoring linear map permissions on execmem cache clean
From: Adrian Barnaś @ 2026-06-24 13:57 UTC (permalink / raw)
To: Mike Rapoport
Cc: Brendan Jackman, linux-arm-kernel, linux-mm, Catalin Marinas,
Will Deacon, Ryan Roberts, David Hildenbrand, Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman, owner-linux-mm
In-Reply-To: <ajLqGZ7sfKsQaSf4@kernel.org>
On Wed, Jun 17, 2026 at 09:40:25PM +0300, Mike Rapoport wrote:
>Hi Adrian,
>
>On Wed, Jun 17, 2026 at 03:18:27PM +0000, Adrian Barnaś wrote:
>> On Fri, Jun 12, 2026 at 10:17:55AM +0300, Mike Rapoport wrote:
>> > >
>> > > Hm, maybe desirable for execmem but that doesn't really mean the x86
>> > > behaviour is correct. Maybe it makes more sense to change the x86
>> > > to align with the arm64 behaviour here?
>> > >
>> > > BTW we should probably document this API a little bit, I never thought
>> > > abut what "valid" actually means until now. I had thought of it as "I
>> > > can access this memory" but that's an unclear concept and now I realise
>> > > "valid" is a technical concept in Arm that's confusing. And it's extra
>> > > confusing if the kernel API uses "valid" to mean a _different_ thing.
>> >
>> > I've got confused too and that's how set_direct_map_valid() got into x86
>> > with a different semantics than on arm64.
>> >
>> > What execmem really needs is set_direct_map_default() variant that gets
>> > nr_pages.
>> >
>> > AFAIR, set_direct_map_default() has a single 'page' parameter because it
>> > was added to reset permissions for the direct map alias for vmalloc()'ed
>> > pages before there was VMALLOC_HUGE and each page had to be reset
>> > independently anyway.
>> >
>> > Maybe it's time to add nr_pages to set_direct_map_valid().
>>
>> I was also quite confused by this initially. I spent some time debugging
>> until I realized why unloading all the modules was causing the kernel to
>> crash.
>>
>> The reason I took this approach was that I wanted to send out a working
>> prototype for arm64 that wouldn't interfere with the existing, working
>> implementation on x86.
>>
>> Following your suggestion, I can put together a preparatory patch series to
>> refactor the set_direct_map_* APIs to accept a nr_pages parameter. This
>
>There was a patch Nikita sent a while ago that does something similar:
>
>https://lore.kernel.org/all/20260410151746.61150-2-kalyazin@amazon.com
>
>I believe you can start from there.
>
I will pick the 01 patch from there to my series.
>> refactoring would also allow us to drop the redundant set_area_direct_map
>
>We can't drop set_area_direct_map() because vmalloc pages might be not
>physically contiguous.
>
Agree.
>> helper. I could then rebase the rox_cache series on top of that.
>>
>> Does this sound like a good path forward?
>>
>> Thanks,
>> Adrian
>
>--
>Sincerely yours,
>Mike.
Thanks,
Adrian
^ permalink raw reply
* [PATCH v4 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- Disable nfc node by default ahead of nand_rb0 pin addition.
- Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
- Disable pcie_phy by default to suppress probe warning.
- Re-enable pcie_phy on S400 board to preserve PCIe functionality.
- Enable mipi_pcie_analog_dphy for PCIe on S400 board.
Changes in v4:
- Add patch to enable mipi_pcie_analog_dphy for PCIe on S400 board.
- Link to v3:
https://lore.kernel.org/all/20260617082239.645562-1-jerrysteve1101@gmail.com/
Changes in v3:
- squash "disable pcie_phy node by default" and "enable pcie_phy in
meson-axg-s400" patches
- Link to v2:
https://lore.kernel.org/all/20260617071604.635627-1-jerrysteve1101@gmail.com/
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (4):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for
PCIe
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 8 ++++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* Re: [RFC PATCH 2/6] arm64: mm: allow huge vmap permission adjustments with bbml2_no_abort
From: Adrian Barnaś @ 2026-06-24 13:54 UTC (permalink / raw)
To: Ryan Roberts
Cc: linux-arm-kernel, linux-mm, Catalin Marinas, Will Deacon,
David Hildenbrand, Mike Rapoport (Microsoft), Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman
In-Reply-To: <07ab8b6f-cb58-4f8c-af7e-c99c2fb8933a@arm.com>
On Thu, Jun 18, 2026 at 03:21:24PM +0100, Ryan Roberts wrote:
>On 11/06/2026 14:01, Adrian Barnaś wrote:
>> Remove the protection against huge vmap permission adjustments on
>> systems that support the bbml2_no_abort CPU feature.
>>
>> Splitting live kernel VA section mappings into page mappings was
>> restricted because it could cause TLB Conflict Aborts. This forced
>> permission adjustments on memory allocated with VM_ALLOW_HUGE_VMAP to be
>> rejected, resulting in performance drops (e.g., when enforcing rodata=on
>> disables huge mappings).
>>
>> The bbml2_no_abort feature (which mirrors the architectural guarantees of
>> FEAT_BBML3) ensures that changing between table and block sizes without
>> following a break-before-make sequence will not generate a TLB Conflict
>> Abort. This hardware guarantee makes it safe to allow dynamic permission
>> adjustments on huge vmap regions.
>
>FYI Linu Cherian has a series that renames bbml2_no_abort to bbml3. I think he's
>planning to post at -rc1. Would be good to rebase this on top once merged.
>
I will keep an eye on next releases.
>>
>> Signed-off-by: Adrian Barnaś <abarnas@google.com>
>> ---
>> arch/arm64/mm/pageattr.c | 22 ++++++++++++++--------
>> 1 file changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>> index 358d1dc9a576..88720bbba892 100644
>> --- a/arch/arm64/mm/pageattr.c
>> +++ b/arch/arm64/mm/pageattr.c
>> @@ -157,23 +157,29 @@ static int change_memory_common(unsigned long addr, int numpages,
>> }
>>
>> /*
>> - * Kernel VA mappings are always live, and splitting live section
>> - * mappings into page mappings may cause TLB conflicts. This means
>> - * we have to ensure that changing the permission bits of the range
>> - * we are operating on does not result in such splitting.
>> - *
>> * Let's restrict ourselves to mappings created by vmalloc (or vmap).
>> - * Disallow VM_ALLOW_HUGE_VMAP mappings to guarantee that only page
>> - * mappings are updated and splitting is never needed.
>> *
>> * So check whether the [addr, addr + size) interval is entirely
>> * covered by precisely one VM area that has the VM_ALLOC flag set.
>> */
>> area = find_vm_area((void *)addr);
>> +
>> if (!area ||
>> ((unsigned long)kasan_reset_tag((void *)end) >
>> (unsigned long)kasan_reset_tag(area->addr) + area->size) ||
>> - ((area->flags & (VM_ALLOC | VM_ALLOW_HUGE_VMAP)) != VM_ALLOC))
>> + !(area->flags & VM_ALLOC))
>> + return -EINVAL;
>> +
>> + /*
>> + * Kernel VA mappings are always live, and splitting live section
>> + * mappings into page mappings may cause TLB conflicts if bbml2_noabort
>> + * is not present.
>> + *
>> + * While bbml2_noabort is not present disallow VM_ALLOW_HUGE_VMAP mappings
>> + * to guarantee that only page mappings are updated and splitting is not
>> + * needed.
>> + */
>> + if (!system_supports_bbml2_noabort() && (area->flags & (VM_ALLOW_HUGE_VMAP)))
>
>nit: no need for the parentheses around VM_ALLOW_HUGE_VMAP.
>
>With that:
>
>Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
>
>> return -EINVAL;
>>
>> if (!numpages)
>
Thanks,
Adrian
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Suzuki K Poulose @ 2026-06-24 13:51 UTC (permalink / raw)
To: Jie Gan, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f39ec59f-97c4-4d5f-bf02-560adae312d9@oss.qualcomm.com>
On 24/06/2026 14:48, Jie Gan wrote:
>
>
> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>> its probe function if the arm,primecell-periphid property is absent.
>>> This causes a deferred probe issue for the TraceNoC device, as the
>>> CID/PID cannot be read from the periphid register.
>>
>> Why does it probe defer?
>>
>
> For an AMBA device, the periphid is mandatory for probing. In the
> amba_match function, AMBA attempts to read the periphid from the CID/PID
> registers if the arm,primecell-periphid property is absent in the device
> tree. If this read fails, it returns -EPROBE_DEFER, and the probe
> ultimately fails.
Why does it fail ? power management ? hw broken ? Is it really AMBA or
do you pretend that to be an AMBA device by faking the CID/PID?
Suzuki
> Most AMBA devices expose valid CID/PID registers, so specifying
> arm,primecell-periphid in the device tree is usually unnecessary.
> However, for the TraceNoC device in this case, AMBA cannot reliably read
> the periphid from the corresponding registers.
>
>> And is this required for all TNOC devices?
>
> So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
> platforms, and all exhibit probe failures due to the same root cause.
>
> I prefer to fix it on Kaanapali first.
>
> Thanks,
> Jie
>
>>
>> Konrad
>
^ permalink raw reply
* Re: [RFC PATCH 3/6] arm64: mm: fix restoring linear map permissions on execmem cache clean
From: Adrian Barnaś @ 2026-06-24 13:52 UTC (permalink / raw)
To: Ryan Roberts
Cc: linux-arm-kernel, linux-mm, Catalin Marinas, Will Deacon,
David Hildenbrand, Mike Rapoport (Microsoft), Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman
In-Reply-To: <751c564b-d6c3-4bd5-a269-e3de89e8cf13@arm.com>
On Fri, Jun 19, 2026 at 09:33:18AM +0100, Ryan Roberts wrote:
>On 18/06/2026 16:05, Ryan Roberts wrote:
>> On 11/06/2026 14:01, Adrian Barnaś wrote:
>>> Strip the read-only attribute from the selected memory range when
>>> restoring the linear map after an execmem cache clean.
>>>
>>> An execmem cache clean is performed when a cache block becomes empty
>>> after unloading a module. When making the memory valid again, the linear
>>> memory alias must also have its read-only attribute cleared.
>>>
>>> Without this change, the linear memory alias remains read-only even
>>> after the execmem cache block itself is freed, which prevents subsequent
>>> allocations from writing to that memory.
>>>
>>> Signed-off-by: Adrian Barnaś <abarnas@google.com>
>>> ---
>>> arch/arm64/mm/pageattr.c | 17 ++++++++++++++++-
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>>> index 88720bbba892..eaefdf90b0d5 100644
>>> --- a/arch/arm64/mm/pageattr.c
>>> +++ b/arch/arm64/mm/pageattr.c
>>> @@ -239,6 +239,13 @@ int set_memory_x(unsigned long addr, int numpages)
>>> __pgprot(PTE_PXN));
>>> }
>>>
>>> +static int set_memory_default(unsigned long addr, int numpages)
>>> +{
>>> + return __change_memory_common(addr, PAGE_SIZE * numpages,
>>> + __pgprot(PTE_VALID),
>>> + __pgprot(PTE_RDONLY));
>>
>> This is not sufficient to convert an invalid entry to valid. As well as setting
>> the PTE_VALID bit, you would also need to clear the PTE_PRESENT_INVALID and set
>> PTE_MAYBE_NG.
>>
>> e.g:
>>
>> int set_memory_valid(unsigned long addr, int numpages, int enable)
>> {
>> if (enable)
>> return __change_memory_common(addr, PAGE_SIZE * numpages,
>> __pgprot(PTE_PRESENT_VALID_KERNEL),
>> __pgprot(PTE_PRESENT_INVALID));
>>
Thanks, I will fix that
>>
>>> +}
>>> +
>>> int set_memory_valid(unsigned long addr, int numpages, int enable)
>>> {
>>> if (enable)
>>> @@ -362,7 +369,15 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
>>> if (!can_set_direct_map())
>>> return 0;
>>>
>>> - return set_memory_valid(addr, nr, valid);
>>> + /*
>>> + * Execmem cache uses this function to reset permissions on linear mapping
>>> + * when freeing unused cache block. On x86 it makes memory RW which is
>>> + * desirable. On ARM64 set_memory_valid() just change valid bit which
>>> + * leave direct mapping read-only so use set_memory_default instead.
>>> + */
>>> +
>>> + return valid ? set_memory_default(addr, nr) :
>>> + set_memory_valid(addr, nr, false);
>>
>> Surely execmem should just be using set_direct_map_default_noflush() if that's
>> the behaviour it wants?
>>
>> I think that the current implementation of set_direct_map_default_noflush()
>> doesn't undo the effects of set_memory_nx() / set_memory_x(). That might be
>> worth checking?
>
>It's also worth mentioning that set_direct_map_valid_noflush() has "noflush" in
>the name, implies it doesn't expect/require any TLB flushing to occur. But the
>implementation will perform tlb flushing for any case that is not just a
>invalid->valid transition (which for the existing impl is the case when
>valid=true and for your changes is never the case - see __change_memory_common).
>
>But execmem doesn't do any tlb flushing so it looks to me like it actually
>requires that set_direct_map_valid_noflush() handles the tlb flushing? All seems
>a bit fishy and probably warrants a cleanup to make things clearer.
>
I think that the clean approach would be to have the `set_direct_map_default`
function (without `noflush`) that does flushing as needed (like the current
one on ARM64). I am not entirely sure but x86 seems to handle permission
faults gracefully while on ARM64 those would cause panics. Is that correct?
>>
>> Thanks,
>> Ryan
>>
>>
>>> }
>>>
>>> #ifdef CONFIG_DEBUG_PAGEALLOC
>>
>
Thanks,
Adrian
^ permalink raw reply
* Re: [PATCH v6 0/2] add mcf54415 DAC driver
From: Angelo Dureghello @ 2026-06-24 13:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Angelo Dureghello, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Geert Uytterhoeven, Maxime Coquelin,
Alexandre Torgue, linux-kernel, linux-iio, linux-m68k,
linux-stm32, linux-arm-kernel
In-Reply-To: <ajr4LvdPZKHrqDVp@ashevche-desk.local>
Hi Andy,
On Wed, Jun 24, 2026 at 12:18:38AM +0300, Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 11:04:14PM +0200, Angelo Dureghello wrote:
> > This patchset adds a minimalistic DAC driver for the NXP mcf54415/6/7/8
> > builtin DACs.
> >
> > Currently the driver enables the raw write only. Feature as dma, sync, or
> > format are not supoprted for this version.
> >
> > Additional options suppoerted by the DAC module will be added to the driver
> > later on, as needed.
> >
> > The same patchset prepares the m68k/coldfire architecture to support
> > the driver.
> >
> > Below some basic tests done on stmark2 mcf54415-based board, voltage check
> > on DAC0 and DAC1:
> >
> > ~ # cd /sys/bus/iio/devices/iio:device0/
> > /sys/bus/iio/devices/iio:device0 # ls
> > name out_voltage_scale uevent
> > out_voltage_raw subsystem
> > /sys/bus/iio/devices/iio:device0 # cat name
> > mcf54415
> > /sys/bus/iio/devices/iio:device0 # echo 4095 > out_voltage_raw
> > /sys/bus/iio/devices/iio:device0 # echo 2048 > out_voltage_raw
> > /sys/bus/iio/devices/iio:device0 # echo 4096 > out_voltage_raw
> > sh: write error: Invalid argument
> > /sys/bus/iio/devices/iio:device0 # cat out_voltage_raw
> > 2048
> > /sys/bus/iio/devices/iio:device0 #
> >
> > Same behavior for /sys/bus/iio/devices/iio:device1.
> >
> > Generated a sine wave by shell script, sine shape is good.
>
> Heard a presentation (Embedded Recipes IIRC) where one tried sine and real
> sound (it was about sound DAC) was really awful. So, Can you try a bit more
> sophisticated signal?
>
sure can try some sound with this 12-bit, but don't think is possible now
with only raw output. My idea is with further patches, once ColdFire DMA
is fixed, to extend the driver and be able to sample higher frequencies.
> --
> With Best Regards,
> Andy Shevchenko
>
>
Regards,
angelo
^ permalink raw reply
* Re: [PATCH] spi: imx: reconfigure for PIO when DMA cannot be started
From: Javier Fernandez Pastrana @ 2026-06-24 13:49 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: Mark Brown, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Carlos Song, linux-spi@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB68027B9C426D7CD42E256B92E8ED2@AM0PR04MB6802.eurprd04.prod.outlook.com>
Hi Carlos,
On Wed, 24 Jun 2026 09:22:02 +0000
"Carlos Song (OSS)" <carlos.song@oss.nxp.com> wrote:
> > -----Original Message-----
> > From: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
> > Sent: Tuesday, June 23, 2026 11:33 PM
> > To: Mark Brown <broonie@kernel.org>; Frank Li <frank.li@nxp.com>;
> > Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Carlos
> > Song <carlos.song@nxp.com>; linux-spi@vger.kernel.org;
> > imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org Cc: javier.pastrana@linutronix.de;
> > stable@vger.kernel.org Subject: [PATCH] spi: imx: reconfigure for
> > PIO when DMA cannot be started
> >
> > [You don't often get email from javier.pastrana@linutronix.de.
> > Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > 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);
>
> Hi, Javier
>
> Thank you very much for fixing this issue!
>
> You can remove this line also: spi_imx->usedma = false;
> Because spi_imx_setupxfer() will recheck spi_imx_can_dma() and return
> false because controller->fallback = true;
>
> How do you think about it?
Good catch. You're right, spi_imx_setupxfer() rechecks
spi_imx_can_dma(), so spi_imx->usedma = false is redundant.
I'll remove it in v2.
Thanks for reviewing!
>
> Carlos Song
>
> > if (spi_imx->target_mode)
> > return
> > spi_imx_pio_transfer_target(spi, transfer);
> > else
> > --
> > 2.47.3
> >
>
Javier
--
Javier Fernandez Pastrana
Linutronix GmbH | Bahnhofstraße 3 | D-88690 Uhldingen-Mühlhofen
Phone: +49 7556 25 999 32; Fax.: +49 7556 25 999 99
Hinweise zum Datenschutz finden Sie hier (Informations on data privacy
can be found here): https://linutronix.de/legal/data-protection.php
Linutronix GmbH | Firmensitz (Registered Office): Uhldingen-Mühlhofen |
Registergericht (Registration Court): Amtsgericht Freiburg i.Br., HRB700
806 | Geschäftsführer (Managing Directors): Heinz Egger, Thomas
Gleixner, Sharon Heck, Yulia Beck, Tiffany Silva
^ permalink raw reply
* Re: [PATCH v15 06/11] arm64: ptrace: Move rseq_syscall() before audit_syscall_exit()
From: Ada Couprie Diaz @ 2026-06-24 13:46 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-7-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Move the rseq_syscall() check earlier in the syscall exit path to ensure
> it operates on the original instruction pointer (regs->pc) before any
> potential modification by a tracer.
>
> [Background]
> When CONFIG_DEBUG_RSEQ is enabled, rseq_syscall() verifies that a system
> call was not executed within an rseq critical section by examining
> regs->pc. If a violation is detected, it triggers a SIGSEGV.
>
> [Problem]
> Currently, arm64 invokes rseq_syscall() after report_syscall_exit().
> However, during report_syscall_exit(), a ptrace tracer can modify the
> task's instruction pointer via PTRACE_SETREGS. This leads to an
> inconsistency where rseq may analyze a post-trace PC instead of the
> actual PC at the time of syscall exit.
>
> [Why this matters]
> The rseq check is intended to validate the execution context of the
> syscall itself. Analyzing a tracer-modified PC can lead to incorrect
> detection or missed violations. Moving the check earlier ensures rseq
> sees the authentic state of the task.
>
> [Alignment]
> This change aligns arm64 with:
> - Generic entry, which calls rseq_syscall() first.
> - arm32 implementation, which also performs the check before audit.
>
> [Impact]
> There is no functional change to signal delivery; SIGSEGV will still be
> processed in arm64_exit_to_user_mode() at the end of the exit path.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 05/11] arm64/ptrace: Use syscall_get_arguments() helper for audit
From: Ada Couprie Diaz @ 2026-06-24 13:44 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-6-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Extract syscall_enter_audit() helper and use syscall_get_arguments()
> to get syscall arguments, matching the generic entry implementation.
>
> The new code:
> - Checks audit_context() first to avoid unnecessary memcpy when audit
> is not active.
> - Uses syscall_get_arguments() helper instead of directly accessing
> regs fields.
> - Is now exactly equivalent to generic entry's syscall_enter_audit().
>
> No functional changes.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 13:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-copper-albatross-of-youth-6abae8@quoll>
Hi Krzysztof,
> Please start testing your patches. This for sure fails tests.
>
> It does not look like you tested the DTS against bindings. Please run
> 'make dtbs_check W=1' (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
You are right, I had tested my patches but wrongly. It is indeed failling.
I'm very sorry for that. Thank's for taking the time to explain.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH v15 04/11] arm64/ptrace: Expand secure_computing() in place
From: Ada Couprie Diaz @ 2026-06-24 13:43 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-5-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor syscall_trace_enter() by open-coding the seccomp check
> to align with the generic entry framework.
>
> [Background]
> The generic entry implementation expands the seccomp check in-place
> instead of using the secure_computing() wrapper. It directly tests
> SYSCALL_WORK_SECCOMP and calls the underlying __secure_computing()
> function to handle syscall filtering.
>
> [Changes]
> 1. Open-code seccomp check:
> - Instead of calling the secure_computing() wrapper, explicitly check
> the 'flags' parameter for _TIF_SECCOMP.
> - Call __secure_computing() directly if the flag is set.
>
> [Why this matters]
> - Aligns the arm64 syscall path with the generic entry implementation,
> simplifying future migration to the generic entry framework.
> - No functional changes are intended; seccomp behavior remains identical.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ 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