* Re: [PATCH 4/5] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Christoph Hellwig @ 2026-03-30 5:32 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Christoph Hellwig, Ard Biesheuvel, linux-raid, linux-arm-kernel,
linux-crypto, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <cca6facc-6c37-48d0-81e6-f8568f36b91d@app.fastmail.com>
On Fri, Mar 27, 2026 at 03:45:56PM +0100, Ard Biesheuvel wrote:
> On Fri, 27 Mar 2026, at 14:50, Christoph Hellwig wrote:
> > On Fri, Mar 27, 2026 at 12:30:52PM +0100, Ard Biesheuvel wrote:
> >> From: Ard Biesheuvel <ardb@kernel.org>
> >>
> >> Tweak the arm64 code so that the pure NEON intrinsics implementation of
> >> XOR is shared between arm64 and ARM.
> >
> > Instead of hiding the implementation in a header, just split xor-neon.c
> > into two .c files, one of which could be built by arm32 as well.
>
> That is what patch 3/5 does. This patch wires up that version into arm64, and drops the copy that has become redundant as a result.
Yeah, sorry - I misread the series a little.
>
> > probably
> > in the arm/ instead of the arm64/ subdirectory, but we can also add a
> > new arm-common one if that's what the arm maintainers prefer.
>
> Having the shared pure NEON version in arm/ is perfectly fine.
So here would be my preference:
- keep all the arm/arm64 code in lib/raid/xor/arm
- have the neon and EOR3 code in a single xor-neon.c file, with an
ifdef CONFIG_ARM64 around the EOE3 routines
This avoid the including of .c files which is always a bit ugly.
But if there is a strong argument to prefer including of the .c file I
can live with that as well.
>
> Building it as a separate compilation unit for arm64 should also be straight-forward, the only issue is that the 2-way NEON version needs to be shared with the EOR3 compilation unit.
>
---end quoted text---
^ permalink raw reply
* Re: [PATCH v2] raid6: arm64: add SVE optimized implementation for syndrome generation
From: Christoph Hellwig @ 2026-03-30 5:30 UTC (permalink / raw)
To: Demian Shulhan
Cc: Mark Rutland, Ard Biesheuvel, Christoph Hellwig, Song Liu,
Yu Kuai, Will Deacon, Catalin Marinas, broonie, linux-arm-kernel,
robin.murphy, Li Nan, linux-raid, linux-kernel
In-Reply-To: <CAOLeWCsxhzdxQviizJ4X4VOp_28LCtO-RjWoCcZG29rQw86NVg@mail.gmail.com>
On Sun, Mar 29, 2026 at 04:01:06PM +0300, Demian Shulhan wrote:
> Furthermore, as Christoph suggested, I tested scalability on wider
> arrays since the default kernel benchmark is hardcoded to 8 disks,
> which doesn't give the unrolled SVE loop enough data to shine. On a
> 16-disk array, svex4 hits 15.1 GB/s compared to 8.0 GB/s for neonx4.
> On a 24-disk array, while neonx4 chokes and drops to 7.8 GB/s, svex4
> maintains a stable 15.0 GB/s — effectively doubling the throughput.I
> agree this patch should be put on hold for now. My intention is to
> leave these numbers here as evidence that implementing SVE context
> preservation in the kernel (the "good use case") is highly justifiable
> from both a power-efficiency and a wide-array throughput perspective
> for modern ARM64 hardware.
>
> Thanks again for your time and time and review!
To me this sounds like an interesting case for a SVE kernel API.
But I'm not relly knowledgeable enough to provide one to help
with testing this further.
^ permalink raw reply
* Re: [PATCH v2 04/30] KVM: arm64: Isolate mmap_read_lock inside new kvm_s2_fault_get_vma_info() helper
From: Anshuman Khandual @ 2026-03-30 4:57 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-5-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Extract the VMA lookup and metadata snapshotting logic from
> kvm_s2_fault_pin_pfn() into a tightly-scoped sub-helper.
>
> This refactoring structurally fixes a TOCTOU (Time-Of-Check to
> Time-Of-Use) vulnerability and Use-After-Free risk involving the vma
> pointer. In the previous layout, the mmap_read_lock is taken, the vma is
> looked up, and then the lock is dropped before the function continues to
> map the PFN. While an explicit vma = NULL safeguard was present, the vma
> variable was still lexically in scope for the remainder of the function.
>
> By isolating the locked region into kvm_s2_fault_get_vma_info(), the vma
> pointer becomes a local variable strictly confined to that sub-helper.
> Because the pointer's scope literally ends when the sub-helper returns,
> it is not possible for the subsequent page fault logic in
> kvm_s2_fault_pin_pfn() to accidentally access the vanished VMA,
> eliminating this bug class by design.
Makes sense.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 5079a58b65b14..1f2c2200ccd8d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1740,7 +1740,7 @@ struct kvm_s2_fault {
> vm_flags_t vm_flags;
> };
>
> -static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> +static int kvm_s2_fault_get_vma_info(struct kvm_s2_fault *fault)
> {
> struct vm_area_struct *vma;
> struct kvm *kvm = fault->vcpu->kvm;
> @@ -1774,9 +1774,6 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
>
> fault->is_vma_cacheable = kvm_vma_is_cacheable(vma);
>
> - /* Don't use the VMA after the unlock -- it may have vanished */
> - vma = NULL;
> -
> /*
> * Read mmu_invalidate_seq so that KVM can detect if the results of
> * vma_lookup() or __kvm_faultin_pfn() become stale prior to
> @@ -1788,6 +1785,17 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> fault->mmu_seq = kvm->mmu_invalidate_seq;
> mmap_read_unlock(current->mm);
>
> + return 0;
> +}
> +
> +static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> +{
> + int ret;
> +
> + ret = kvm_s2_fault_get_vma_info(fault);
> + if (ret)
> + return ret;
> +
> fault->pfn = __kvm_faultin_pfn(fault->memslot, fault->gfn,
> fault->write_fault ? FOLL_WRITE : 0,
> &fault->writable, &fault->page);
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
From: Canfeng Zhuang @ 2026-03-30 4:36 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: konradybcio, andersson, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-arm-kernel
In-Reply-To: <smbe2ltwykqvlzhryclcm5p7wdhjb72tzuqoramjynrsz35tmb@q6l2osdzflvn>
在 2026/3/29 19:08, Dmitry Baryshkov 写道:
> On Fri, Mar 27, 2026 at 04:31:01PM +0800, Canfeng Zhuang wrote:
>> The monaco-evk mezzanine connector supports a robot expansion board that
>> requires UART6, which is currently disabled. This prevents the expansion
>> board from exchanging data and control commands.
>>
>> Enable UART6 and assign the serial2 alias to provide stable device
>> enumeration for the expansion board.
>>
>> Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/monaco-evk.dts | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
>> index 565418b86b2a..0b26861eac02 100644
>> --- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
>> +++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
>> @@ -21,6 +21,7 @@ aliases {
>> ethernet0 = ðernet0;
>> i2c1 = &i2c1;
>> serial0 = &uart7;
>> + serial2 = &uart6;
>
> What happened to serial1?
>
>> };
>>
>> chosen {
>
serial1 is used for Bluetooth.
Bluetooth support has not been merged yet because it depends on the ongoing
M.2 solution. Once the M.2 solution is finalized and merged, the
Bluetooth-related DTS will be updated accordingly.
The relevant M.2 work is tracked here:
https://lore.kernel.org/all/20260317-pci-m2-e-v6-9-9c898f108d3d@oss.qualcomm.com/
The initial Bluetooth DTS work can be found here:
https://lore.kernel.org/all/20251113130519.2647081-1-wei.deng@oss.qualcomm.com/
Canfeng
^ permalink raw reply
* Re: [PATCH v2 03/30] KVM: arm64: Extract PFN resolution in user_mem_abort()
From: Anshuman Khandual @ 2026-03-30 4:33 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-4-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Extract the section of code responsible for pinning the physical page
> frame number (PFN) backing the faulting IPA into a new helper,
> kvm_s2_fault_pin_pfn().
>
> This helper encapsulates the critical section where the mmap_read_lock
> is held, the VMA is looked up, the mmu invalidate sequence is sampled,
> and the PFN is ultimately resolved via __kvm_faultin_pfn(). It also
> handles the early exits for hardware poisoned pages and noslot PFNs.
>
> By isolating this region, we can begin to organize the state variables
> required for PFN resolution into the kvm_s2_fault struct, clearing out
> a significant amount of local variable clutter from user_mem_abort().
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 105 ++++++++++++++++++++++++-------------------
> 1 file changed, 59 insertions(+), 46 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index b366bde15a429..5079a58b65b14 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1740,55 +1740,11 @@ struct kvm_s2_fault {
> vm_flags_t vm_flags;
> };
>
> -static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> - struct kvm_s2_trans *nested,
> - struct kvm_memory_slot *memslot, unsigned long hva,
> - bool fault_is_perm)
> +static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> {
> - int ret = 0;
> - struct kvm_s2_fault fault_data = {
> - .vcpu = vcpu,
> - .fault_ipa = fault_ipa,
> - .nested = nested,
> - .memslot = memslot,
> - .hva = hva,
> - .fault_is_perm = fault_is_perm,
> - .ipa = fault_ipa,
> - .logging_active = memslot_is_logging(memslot),
> - .force_pte = memslot_is_logging(memslot),
> - .s2_force_noncacheable = false,
> - .vfio_allow_any_uc = false,
> - .prot = KVM_PGTABLE_PROT_R,
> - };
> - struct kvm_s2_fault *fault = &fault_data;
> - struct kvm *kvm = vcpu->kvm;
> struct vm_area_struct *vma;
> - void *memcache;
> - struct kvm_pgtable *pgt;
> - enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
> -
> - if (fault->fault_is_perm)
> - fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu);
> - fault->write_fault = kvm_is_write_fault(fault->vcpu);
> - fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu);
> - VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault);
> + struct kvm *kvm = fault->vcpu->kvm;
>
> - /*
> - * Permission faults just need to update the existing leaf entry,
> - * and so normally don't require allocations from the memcache. The
> - * only exception to this is when dirty logging is enabled at runtime
> - * and a write fault needs to collapse a block entry into a table.
> - */
> - fault->topup_memcache = !fault->fault_is_perm ||
> - (fault->logging_active && fault->write_fault);
> - ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache);
> - if (ret)
> - return ret;
> -
> - /*
> - * Let's check if we will get back a huge page backed by hugetlbfs, or
> - * get block mapping for device MMIO region.
> - */
> mmap_read_lock(current->mm);
> vma = vma_lookup(current->mm, fault->hva);
> if (unlikely(!vma)) {
> @@ -1842,6 +1798,63 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> if (is_error_noslot_pfn(fault->pfn))
> return -EFAULT;
>
> + return 1;
> +}
> +
> +static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> + struct kvm_s2_trans *nested,
> + struct kvm_memory_slot *memslot, unsigned long hva,
> + bool fault_is_perm)
> +{
> + int ret = 0;
> + struct kvm_s2_fault fault_data = {
> + .vcpu = vcpu,
> + .fault_ipa = fault_ipa,
> + .nested = nested,
> + .memslot = memslot,
> + .hva = hva,
> + .fault_is_perm = fault_is_perm,
> + .ipa = fault_ipa,
> + .logging_active = memslot_is_logging(memslot),
> + .force_pte = memslot_is_logging(memslot),
> + .s2_force_noncacheable = false,
> + .vfio_allow_any_uc = false,
> + .prot = KVM_PGTABLE_PROT_R,
> + };
> + struct kvm_s2_fault *fault = &fault_data;
> + struct kvm *kvm = vcpu->kvm;
> + void *memcache;
> + struct kvm_pgtable *pgt;
> + enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
> +
> + if (fault->fault_is_perm)
> + fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu);
> + fault->write_fault = kvm_is_write_fault(fault->vcpu);
> + fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu);
> + VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault);
> +
> + /*
> + * Permission faults just need to update the existing leaf entry,
> + * and so normally don't require allocations from the memcache. The
> + * only exception to this is when dirty logging is enabled at runtime
> + * and a write fault needs to collapse a block entry into a table.
> + */
> + fault->topup_memcache = !fault->fault_is_perm ||
> + (fault->logging_active && fault->write_fault);
> + ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache);
> + if (ret)
> + return ret;
> +
> + /*
> + * Let's check if we will get back a huge page backed by hugetlbfs, or
> + * get block mapping for device MMIO region.
> + */
> + ret = kvm_s2_fault_pin_pfn(fault);
> + if (ret != 1)
> + return ret;
> +
> + ret = 0;
> +
> /*
> * Check if this is non-struct page memory PFN, and cannot support
> * CMOs. It could potentially be unsafe to access as cacheable.
^ permalink raw reply
* Re: [PATCH v2 02/30] KVM: arm64: Introduce struct kvm_s2_fault to user_mem_abort()
From: Anshuman Khandual @ 2026-03-30 4:18 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-3-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> The user_mem_abort() function takes many arguments and defines a large
> number of local variables. Passing all these variables around to helper
> functions would result in functions with too many arguments.
>
> Introduce struct kvm_s2_fault to encapsulate the stage-2 fault state.
> This structure holds both the input parameters and the intermediate
> state required during the fault handling process.
>
> Update user_mem_abort() to initialize this structure and replace the
> usage of local variables with fields from the new structure.
>
> This prepares the ground for further extracting parts of
> user_mem_abort() into smaller helper functions that can simply take a
> pointer to the fault state structure.
>
> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 212 +++++++++++++++++++++++++------------------
> 1 file changed, 123 insertions(+), 89 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index f8064b2d32045..b366bde15a429 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1710,38 +1710,68 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> return vma_shift;
> }
>
> +struct kvm_s2_fault {
> + struct kvm_vcpu *vcpu;
> + phys_addr_t fault_ipa;
> + struct kvm_s2_trans *nested;
> + struct kvm_memory_slot *memslot;
> + unsigned long hva;
> + bool fault_is_perm;
> +
> + bool write_fault;
> + bool exec_fault;
> + bool writable;
> + bool topup_memcache;
> + bool mte_allowed;
> + bool is_vma_cacheable;
> + bool s2_force_noncacheable;
> + bool vfio_allow_any_uc;
> + unsigned long mmu_seq;
> + phys_addr_t ipa;
> + short vma_shift;
> + gfn_t gfn;
> + kvm_pfn_t pfn;
> + bool logging_active;
> + bool force_pte;
> + long vma_pagesize;
> + long fault_granule;
> + enum kvm_pgtable_prot prot;
> + struct page *page;
> + vm_flags_t vm_flags;
> +};
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_s2_trans *nested,
> struct kvm_memory_slot *memslot, unsigned long hva,
> bool fault_is_perm)
> {
> int ret = 0;
> - bool topup_memcache;
> - bool write_fault, writable;
> - bool exec_fault, mte_allowed, is_vma_cacheable;
> - bool s2_force_noncacheable = false, vfio_allow_any_uc = false;
> - unsigned long mmu_seq;
> - phys_addr_t ipa = fault_ipa;
> + struct kvm_s2_fault fault_data = {
> + .vcpu = vcpu,
> + .fault_ipa = fault_ipa,
> + .nested = nested,
> + .memslot = memslot,
> + .hva = hva,
> + .fault_is_perm = fault_is_perm,
> + .ipa = fault_ipa,
> + .logging_active = memslot_is_logging(memslot),
> + .force_pte = memslot_is_logging(memslot),
> + .s2_force_noncacheable = false,
> + .vfio_allow_any_uc = false,
> + .prot = KVM_PGTABLE_PROT_R,
> + };
> + struct kvm_s2_fault *fault = &fault_data;
> struct kvm *kvm = vcpu->kvm;
> struct vm_area_struct *vma;
> - short vma_shift;
> void *memcache;
> - gfn_t gfn;
> - kvm_pfn_t pfn;
> - bool logging_active = memslot_is_logging(memslot);
> - bool force_pte = logging_active;
> - long vma_pagesize, fault_granule;
> - enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
> struct kvm_pgtable *pgt;
> - struct page *page;
> - vm_flags_t vm_flags;
> enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
>
> - if (fault_is_perm)
> - fault_granule = kvm_vcpu_trap_get_perm_fault_granule(vcpu);
> - write_fault = kvm_is_write_fault(vcpu);
> - exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu);
> - VM_WARN_ON_ONCE(write_fault && exec_fault);
> + if (fault->fault_is_perm)
> + fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu);
> + fault->write_fault = kvm_is_write_fault(fault->vcpu);
> + fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu);
> + VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault);
>
> /*
> * Permission faults just need to update the existing leaf entry,
> @@ -1749,8 +1779,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * only exception to this is when dirty logging is enabled at runtime
> * and a write fault needs to collapse a block entry into a table.
> */
> - topup_memcache = !fault_is_perm || (logging_active && write_fault);
> - ret = prepare_mmu_memcache(vcpu, topup_memcache, &memcache);
> + fault->topup_memcache = !fault->fault_is_perm ||
> + (fault->logging_active && fault->write_fault);
> + ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache);
> if (ret)
> return ret;
>
> @@ -1759,33 +1790,33 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * get block mapping for device MMIO region.
> */
> mmap_read_lock(current->mm);
> - vma = vma_lookup(current->mm, hva);
> + vma = vma_lookup(current->mm, fault->hva);
> if (unlikely(!vma)) {
> - kvm_err("Failed to find VMA for hva 0x%lx\n", hva);
> + kvm_err("Failed to find VMA for fault->hva 0x%lx\n", fault->hva);
> mmap_read_unlock(current->mm);
> return -EFAULT;
> }
>
> - vma_shift = kvm_s2_resolve_vma_size(vma, hva, memslot, nested,
> - &force_pte, &ipa);
> - vma_pagesize = 1UL << vma_shift;
> + fault->vma_shift = kvm_s2_resolve_vma_size(vma, fault->hva, fault->memslot, fault->nested,
> + &fault->force_pte, &fault->ipa);
> + fault->vma_pagesize = 1UL << fault->vma_shift;
>
> /*
> * Both the canonical IPA and fault IPA must be aligned to the
> * mapping size to ensure we find the right PFN and lay down the
> * mapping in the right place.
> */
> - fault_ipa = ALIGN_DOWN(fault_ipa, vma_pagesize);
> - ipa = ALIGN_DOWN(ipa, vma_pagesize);
> + fault->fault_ipa = ALIGN_DOWN(fault->fault_ipa, fault->vma_pagesize);
> + fault->ipa = ALIGN_DOWN(fault->ipa, fault->vma_pagesize);
>
> - gfn = ipa >> PAGE_SHIFT;
> - mte_allowed = kvm_vma_mte_allowed(vma);
> + fault->gfn = fault->ipa >> PAGE_SHIFT;
> + fault->mte_allowed = kvm_vma_mte_allowed(vma);
>
> - vfio_allow_any_uc = vma->vm_flags & VM_ALLOW_ANY_UNCACHED;
> + fault->vfio_allow_any_uc = vma->vm_flags & VM_ALLOW_ANY_UNCACHED;
>
> - vm_flags = vma->vm_flags;
> + fault->vm_flags = vma->vm_flags;
>
> - is_vma_cacheable = kvm_vma_is_cacheable(vma);
> + fault->is_vma_cacheable = kvm_vma_is_cacheable(vma);
>
> /* Don't use the VMA after the unlock -- it may have vanished */
> vma = NULL;
> @@ -1798,24 +1829,25 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * Rely on mmap_read_unlock() for an implicit smp_rmb(), which pairs
> * with the smp_wmb() in kvm_mmu_invalidate_end().
> */
> - mmu_seq = kvm->mmu_invalidate_seq;
> + fault->mmu_seq = kvm->mmu_invalidate_seq;
> mmap_read_unlock(current->mm);
>
> - pfn = __kvm_faultin_pfn(memslot, gfn, write_fault ? FOLL_WRITE : 0,
> - &writable, &page);
> - if (pfn == KVM_PFN_ERR_HWPOISON) {
> - kvm_send_hwpoison_signal(hva, vma_shift);
> + fault->pfn = __kvm_faultin_pfn(fault->memslot, fault->gfn,
> + fault->write_fault ? FOLL_WRITE : 0,
> + &fault->writable, &fault->page);
> + if (fault->pfn == KVM_PFN_ERR_HWPOISON) {
> + kvm_send_hwpoison_signal(fault->hva, fault->vma_shift);
> return 0;
> }
> - if (is_error_noslot_pfn(pfn))
> + if (is_error_noslot_pfn(fault->pfn))
> return -EFAULT;
>
> /*
> * Check if this is non-struct page memory PFN, and cannot support
> * CMOs. It could potentially be unsafe to access as cacheable.
> */
> - if (vm_flags & (VM_PFNMAP | VM_MIXEDMAP) && !pfn_is_map_memory(pfn)) {
> - if (is_vma_cacheable) {
> + if (fault->vm_flags & (VM_PFNMAP | VM_MIXEDMAP) && !pfn_is_map_memory(fault->pfn)) {
> + if (fault->is_vma_cacheable) {
> /*
> * Whilst the VMA owner expects cacheable mapping to this
> * PFN, hardware also has to support the FWB and CACHE DIC
> @@ -1833,25 +1865,25 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> } else {
> /*
> * If the page was identified as device early by looking at
> - * the VMA flags, vma_pagesize is already representing the
> + * the VMA flags, fault->vma_pagesize is already representing the
> * largest quantity we can map. If instead it was mapped
> - * via __kvm_faultin_pfn(), vma_pagesize is set to PAGE_SIZE
> + * via __kvm_faultin_pfn(), fault->vma_pagesize is set to PAGE_SIZE
> * and must not be upgraded.
> *
> * In both cases, we don't let transparent_hugepage_adjust()
> * change things at the last minute.
> */
> - s2_force_noncacheable = true;
> + fault->s2_force_noncacheable = true;
> }
> - } else if (logging_active && !write_fault) {
> + } else if (fault->logging_active && !fault->write_fault) {
> /*
> - * Only actually map the page as writable if this was a write
> + * Only actually map the page as fault->writable if this was a write
> * fault.
> */
> - writable = false;
> + fault->writable = false;
> }
>
> - if (exec_fault && s2_force_noncacheable)
> + if (fault->exec_fault && fault->s2_force_noncacheable)
> ret = -ENOEXEC;
>
> if (ret)
> @@ -1860,21 +1892,21 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> /*
> * Guest performs atomic/exclusive operations on memory with unsupported
> * attributes (e.g. ld64b/st64b on normal memory when no FEAT_LS64WB)
> - * and trigger the exception here. Since the memslot is valid, inject
> + * and trigger the exception here. Since the fault->memslot is valid, inject
> * the fault back to the guest.
> */
> - if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(vcpu))) {
> - kvm_inject_dabt_excl_atomic(vcpu, kvm_vcpu_get_hfar(vcpu));
> + if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(fault->vcpu))) {
> + kvm_inject_dabt_excl_atomic(fault->vcpu, kvm_vcpu_get_hfar(fault->vcpu));
> ret = 1;
> goto out_put_page;
> }
>
> - if (nested)
> - adjust_nested_fault_perms(nested, &prot, &writable);
> + if (fault->nested)
> + adjust_nested_fault_perms(fault->nested, &fault->prot, &fault->writable);
>
> kvm_fault_lock(kvm);
> - pgt = vcpu->arch.hw_mmu->pgt;
> - if (mmu_invalidate_retry(kvm, mmu_seq)) {
> + pgt = fault->vcpu->arch.hw_mmu->pgt;
> + if (mmu_invalidate_retry(kvm, fault->mmu_seq)) {
> ret = -EAGAIN;
> goto out_unlock;
> }
> @@ -1883,78 +1915,80 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * If we are not forced to use page mapping, check if we are
> * backed by a THP and thus use block mapping if possible.
> */
> - if (vma_pagesize == PAGE_SIZE && !(force_pte || s2_force_noncacheable)) {
> - if (fault_is_perm && fault_granule > PAGE_SIZE)
> - vma_pagesize = fault_granule;
> + if (fault->vma_pagesize == PAGE_SIZE &&
> + !(fault->force_pte || fault->s2_force_noncacheable)) {
> + if (fault->fault_is_perm && fault->fault_granule > PAGE_SIZE)
> + fault->vma_pagesize = fault->fault_granule;
> else
> - vma_pagesize = transparent_hugepage_adjust(kvm, memslot,
> - hva, &pfn,
> - &fault_ipa);
> + fault->vma_pagesize = transparent_hugepage_adjust(kvm, fault->memslot,
> + fault->hva, &fault->pfn,
> + &fault->fault_ipa);
>
> - if (vma_pagesize < 0) {
> - ret = vma_pagesize;
> + if (fault->vma_pagesize < 0) {
> + ret = fault->vma_pagesize;
> goto out_unlock;
> }
> }
>
> - if (!fault_is_perm && !s2_force_noncacheable && kvm_has_mte(kvm)) {
> + if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm)) {
> /* Check the VMM hasn't introduced a new disallowed VMA */
> - if (mte_allowed) {
> - sanitise_mte_tags(kvm, pfn, vma_pagesize);
> + if (fault->mte_allowed) {
> + sanitise_mte_tags(kvm, fault->pfn, fault->vma_pagesize);
> } else {
> ret = -EFAULT;
> goto out_unlock;
> }
> }
>
> - if (writable)
> - prot |= KVM_PGTABLE_PROT_W;
> + if (fault->writable)
> + fault->prot |= KVM_PGTABLE_PROT_W;
>
> - if (exec_fault)
> - prot |= KVM_PGTABLE_PROT_X;
> + if (fault->exec_fault)
> + fault->prot |= KVM_PGTABLE_PROT_X;
>
> - if (s2_force_noncacheable) {
> - if (vfio_allow_any_uc)
> - prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> + if (fault->s2_force_noncacheable) {
> + if (fault->vfio_allow_any_uc)
> + fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> else
> - prot |= KVM_PGTABLE_PROT_DEVICE;
> + fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> - prot |= KVM_PGTABLE_PROT_X;
> + fault->prot |= KVM_PGTABLE_PROT_X;
> }
>
> - if (nested)
> - adjust_nested_exec_perms(kvm, nested, &prot);
> + if (fault->nested)
> + adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
>
> /*
> * Under the premise of getting a FSC_PERM fault, we just need to relax
> - * permissions only if vma_pagesize equals fault_granule. Otherwise,
> + * permissions only if fault->vma_pagesize equals fault->fault_granule. Otherwise,
> * kvm_pgtable_stage2_map() should be called to change block size.
> */
> - if (fault_is_perm && vma_pagesize == fault_granule) {
> + if (fault->fault_is_perm && fault->vma_pagesize == fault->fault_granule) {
> /*
> * Drop the SW bits in favour of those stored in the
> * PTE, which will be preserved.
> */
> - prot &= ~KVM_NV_GUEST_MAP_SZ;
> - ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault_ipa, prot, flags);
> + fault->prot &= ~KVM_NV_GUEST_MAP_SZ;
> + ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault->fault_ipa, fault->prot,
> + flags);
> } else {
> - ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault_ipa, vma_pagesize,
> - __pfn_to_phys(pfn), prot,
> - memcache, flags);
> + ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault->fault_ipa, fault->vma_pagesize,
> + __pfn_to_phys(fault->pfn), fault->prot,
> + memcache, flags);
> }
>
> out_unlock:
> - kvm_release_faultin_page(kvm, page, !!ret, writable);
> + kvm_release_faultin_page(kvm, fault->page, !!ret, fault->writable);
> kvm_fault_unlock(kvm);
>
> /* Mark the page dirty only if the fault is handled successfully */
> - if (writable && !ret)
> - mark_page_dirty_in_slot(kvm, memslot, gfn);
> + if (fault->writable && !ret)
> + mark_page_dirty_in_slot(kvm, fault->memslot, fault->gfn);
>
> return ret != -EAGAIN ? ret : 0;
>
> out_put_page:
> - kvm_release_page_unused(page);
> + kvm_release_page_unused(fault->page);
> return ret;
> }
>
^ permalink raw reply
* Re: [PATCH v2 01/30] KVM: arm64: Extract VMA size resolution in user_mem_abort()
From: Anshuman Khandual @ 2026-03-30 4:08 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-2-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> As part of an effort to refactor user_mem_abort() into smaller, more
> focused helper functions, extract the logic responsible for determining
> the VMA shift and page size into a new static helper,
> kvm_s2_resolve_vma_size().
>
> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 130 ++++++++++++++++++++++++-------------------
> 1 file changed, 73 insertions(+), 57 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 17d64a1e11e5c..f8064b2d32045 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1639,6 +1639,77 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> return ret != -EAGAIN ? ret : 0;
> }
>
> +static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> + unsigned long hva,
> + struct kvm_memory_slot *memslot,
> + struct kvm_s2_trans *nested,
> + bool *force_pte, phys_addr_t *ipa)
> +{
> + short vma_shift;
> + long vma_pagesize;
> +
> + if (*force_pte)
> + vma_shift = PAGE_SHIFT;
> + else
> + vma_shift = get_vma_page_shift(vma, hva);
> +
> + switch (vma_shift) {
> +#ifndef __PAGETABLE_PMD_FOLDED
> + case PUD_SHIFT:
> + if (fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))
> + break;
> + fallthrough;
> +#endif
> + case CONT_PMD_SHIFT:
> + vma_shift = PMD_SHIFT;
> + fallthrough;
> + case PMD_SHIFT:
> + if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE))
> + break;
> + fallthrough;
> + case CONT_PTE_SHIFT:
> + vma_shift = PAGE_SHIFT;
> + *force_pte = true;
> + fallthrough;
> + case PAGE_SHIFT:
> + break;
> + default:
> + WARN_ONCE(1, "Unknown vma_shift %d", vma_shift);
> + }
> +
> + vma_pagesize = 1UL << vma_shift;
> +
> + if (nested) {
> + unsigned long max_map_size;
> +
> + max_map_size = *force_pte ? PAGE_SIZE : PUD_SIZE;
> +
> + *ipa = kvm_s2_trans_output(nested);
> +
> + /*
> + * If we're about to create a shadow stage 2 entry, then we
> + * can only create a block mapping if the guest stage 2 page
> + * table uses at least as big a mapping.
> + */
> + max_map_size = min(kvm_s2_trans_size(nested), max_map_size);
> +
> + /*
> + * Be careful that if the mapping size falls between
> + * two host sizes, take the smallest of the two.
> + */
> + if (max_map_size >= PMD_SIZE && max_map_size < PUD_SIZE)
> + max_map_size = PMD_SIZE;
> + else if (max_map_size >= PAGE_SIZE && max_map_size < PMD_SIZE)
> + max_map_size = PAGE_SIZE;
> +
> + *force_pte = (max_map_size == PAGE_SIZE);
> + vma_pagesize = min_t(long, vma_pagesize, max_map_size);
> + vma_shift = __ffs(vma_pagesize);
> + }
> +
> + return vma_shift;
> +}
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_s2_trans *nested,
> struct kvm_memory_slot *memslot, unsigned long hva,
> @@ -1695,65 +1766,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> return -EFAULT;
> }
>
> - if (force_pte)
> - vma_shift = PAGE_SHIFT;
> - else
> - vma_shift = get_vma_page_shift(vma, hva);
> -
> - switch (vma_shift) {
> -#ifndef __PAGETABLE_PMD_FOLDED
> - case PUD_SHIFT:
> - if (fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))
> - break;
> - fallthrough;
> -#endif
> - case CONT_PMD_SHIFT:
> - vma_shift = PMD_SHIFT;
> - fallthrough;
> - case PMD_SHIFT:
> - if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE))
> - break;
> - fallthrough;
> - case CONT_PTE_SHIFT:
> - vma_shift = PAGE_SHIFT;
> - force_pte = true;
> - fallthrough;
> - case PAGE_SHIFT:
> - break;
> - default:
> - WARN_ONCE(1, "Unknown vma_shift %d", vma_shift);
> - }
> -
> + vma_shift = kvm_s2_resolve_vma_size(vma, hva, memslot, nested,
> + &force_pte, &ipa);
> vma_pagesize = 1UL << vma_shift;
>
> - if (nested) {
> - unsigned long max_map_size;
> -
> - max_map_size = force_pte ? PAGE_SIZE : PUD_SIZE;
> -
> - ipa = kvm_s2_trans_output(nested);
> -
> - /*
> - * If we're about to create a shadow stage 2 entry, then we
> - * can only create a block mapping if the guest stage 2 page
> - * table uses at least as big a mapping.
> - */
> - max_map_size = min(kvm_s2_trans_size(nested), max_map_size);
> -
> - /*
> - * Be careful that if the mapping size falls between
> - * two host sizes, take the smallest of the two.
> - */
> - if (max_map_size >= PMD_SIZE && max_map_size < PUD_SIZE)
> - max_map_size = PMD_SIZE;
> - else if (max_map_size >= PAGE_SIZE && max_map_size < PMD_SIZE)
> - max_map_size = PAGE_SIZE;
> -
> - force_pte = (max_map_size == PAGE_SIZE);
> - vma_pagesize = min_t(long, vma_pagesize, max_map_size);
> - vma_shift = __ffs(vma_pagesize);
> - }
> -
> /*
> * Both the canonical IPA and fault IPA must be aligned to the
> * mapping size to ensure we find the right PFN and lay down the
^ permalink raw reply
* Re: [PATCH v5 2/8] ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes
From: Kevin Tung @ 2026-03-30 3:15 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Amithash Prasasd, Kevin Tung, Ken Chen, Leo Yang, Jackson Liu,
Daniel Hsu
In-Reply-To: <d7794f74b26bbc1ee0a70e39c5671acc018f80eb.camel@codeconstruct.com.au>
On Thu, Mar 26, 2026 at 2:07 PM Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> Hi Kevin,
>
> Sorry for the delay.
>
> On Mon, 2026-03-09 at 11:41 -0700, Kevin Tung wrote:
> > On Tue, Mar 3, 2026 at 6:41 PM Andrew Jeffery
> > <andrew@codeconstruct.com.au> wrote:
> > >
> > > Hi Kevin,
> > >
> > > Sorry for the patchy replies so far, but this series bothers me and
> > > other priorities keep bumping it down the list.
> > >
> > > On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote:
> > > > Two different power monitor devices, using different drivers, reuse
> > > > I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants.
> > > > Defining these devices statically in the DTS can lead to incorrect
> > > > driver binding on newer boards when the wrong device is instantiated.
> > >
> > > There are effective methods of maintaining devicetrees for variants.
> > > Why are we choosing to remove information about the platform rather
> > > than use existing techniques to properly describe them?
> > >
> > Hi Andrew,
> >
> > This is due to hardware design changes during earlier development
> > stages, and the fix is expected to remain stable as the design has
> > matured.
> > Could you guide me on the best way to maintain devicetrees for
> > variants? Thank you :)
>
> My expectation is your platforms move through several design phases
> prior to (mass?) production. My suspicion is that you have sent a
> devicetree for the pre-production design phases, and you're trying to
> evolve that one devicetree to match the design for whatever current
> phase you're in.
>
> So, ideally: Send a devicetree only for the finalised design. Don't
> send devicetrees for pre-production designs.
>
> If you feel you can't do that for some reason, an alternative is to
> have a separate .dts file for each phase in the design process.
>
> This may sound tedious but it doesn't have to be a burden to maintain.
>
> For instance, you can use one or more .dtsi files to describe the
> common components and relationships for your platform. These .dtsi
> files are then #included into .dts files as usual. Often .dtsi files
> are used to isolate different hardware scopes (SoC vs board, for
> instance), but we're not limited to that, we can use them for the
> purpose outlined above too.
>
> If there are only (very) minor differences, there's also the option of
> #including another .dts file. From there you can adjust properties or
> even delete nodes where it makes sense. For example, we maintain a .dts
> file for the latest revision of the AST2600-EVB, but we also have a
> separate .dts for the A1 revision with a different regulator setup:
>
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts?h=v7.0-rc5
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb-a1.dts?h=v7.0-rc5
>
> Any of these are better options than this current approach of trying to
> justify incompatible changes against unclear design boundaries.
>
> Andrew
Hi Andrew,
Thank you for the guidance.
We will submit devicetree changes for the finalized design and ensure
they align with the hardware to maintain stability and avoid
incompatible changes.
Kevin
^ permalink raw reply
* RE: [PATCH v5 08/10] clk: realtek: Add support for MMC-tuned PLL clocks
From: Yu-Chun Lin [林祐君] @ 2026-03-30 3:00 UTC (permalink / raw)
To: Stephen Boyd, afaerber@suse.com, conor+dt@kernel.org,
Edgar Lee [李承諭],
Jyan Chou [周芷安], krzk+dt@kernel.org,
mturquette@baylibre.com, p.zabel@pengutronix.de, robh@kernel.org
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <177440366488.5403.14385693004290004608@localhost.localdomain>
> Quoting Yu-Chun Lin (2026-03-23 19:53:29)
> > diff --git a/drivers/clk/realtek/clk-pll-mmc.c
> > b/drivers/clk/realtek/clk-pll-mmc.c
> > new file mode 100644
> > index 000000000000..017663738c1f
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-pll-mmc.c
> > @@ -0,0 +1,399 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2021 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include "clk-pll.h"
>
> Include what you use in this C file, not just this header file. That makes it
> simpler to see what is used without following include trails.
Got it. I will explicitly include the required headers directly in this .c file.
> > +
> > +#define PLL_EMMC1_OFFSET 0x0
> > +#define PLL_EMMC2_OFFSET 0x4
> > +#define PLL_EMMC3_OFFSET 0x8
> > +#define PLL_EMMC4_OFFSET 0xc
> > +#define PLL_SSC_DIG_EMMC1_OFFSET 0x0
> > +#define PLL_SSC_DIG_EMMC3_OFFSET 0xc
> > +#define PLL_SSC_DIG_EMMC4_OFFSET 0x10
> > +
> > +#define PLL_MMC_SSC_DIV_N_VAL 0x1b
> > +
> > +#define PLL_PHRT0_MASK BIT(1)
> > +#define PLL_PHSEL_MASK GENMASK(4, 0)
> > +#define PLL_SSCPLL_RS_MASK GENMASK(12, 10)
> > +#define PLL_SSCPLL_ICP_MASK GENMASK(9, 5)
> > +#define PLL_SSC_DIV_EXT_F_MASK GENMASK(25, 13)
> > +#define PLL_PI_IBSELH_MASK GENMASK(28, 27)
> > +#define PLL_SSC_DIV_N_MASK GENMASK(23, 16)
> > +#define PLL_NCODE_SSC_EMMC_MASK GENMASK(20, 13)
> > +#define PLL_FCODE_SSC_EMMC_MASK GENMASK(12, 0)
> > +#define PLL_GRAN_EST_EM_MC_MASK GENMASK(20, 0)
> > +#define PLL_EN_SSC_EMMC_MASK BIT(0)
> > +#define PLL_FLAG_INITAL_EMMC_MASK BIT(1)
> [...]
> > diff --git a/drivers/clk/realtek/clk-pll.h
> > b/drivers/clk/realtek/clk-pll.h index 2d27a44a270c..9cf219871218
> > 100644
> > --- a/drivers/clk/realtek/clk-pll.h
> > +++ b/drivers/clk/realtek/clk-pll.h
> > @@ -44,4 +44,25 @@ static inline struct clk_pll *to_clk_pll(struct
> > clk_hw *hw) extern const struct clk_ops rtk_clk_pll_ops; extern
> > const struct clk_ops rtk_clk_pll_ro_ops;
> >
> > +struct clk_pll_mmc {
> > + struct clk_regmap clkr;
> > + int pll_ofs;
> > + int ssc_dig_ofs;
>
> These offsets should be unsigned?
>
Yes, I will fix it.
> > + struct clk_hw phase0_hw;
> > + struct clk_hw phase1_hw;
> > + u32 set_rate_val_53_97_set_ipc: 1;
>
> bool? Doubt we care about this unless we're packing structs (which we
> shouldn't be).
>
This member is actually redundant, so I will just remove it.
> > +};
> > +
> > +#define __clk_pll_mmc_hw(_ptr) __clk_regmap_hw(&(_ptr)->clkr)
> > +
> > +static inline struct clk_pll_mmc *to_clk_pll_mmc(struct clk_hw *hw) {
> > + struct clk_regmap *clkr = to_clk_regmap(hw);
> > +
> > + return container_of(clkr, struct clk_pll_mmc, clkr); }
Best regards,
Yu-Chun
^ permalink raw reply
* RE: [PATCH v5 01/10] dt-bindings: clock: Add Realtek RTD1625 Clock & Reset Controller
From: Yu-Chun Lin [林祐君] @ 2026-03-30 2:48 UTC (permalink / raw)
To: Stephen Boyd, afaerber@suse.com, conor+dt@kernel.org,
Edgar Lee [李承諭],
Jyan Chou [周芷安], krzk+dt@kernel.org,
mturquette@baylibre.com, p.zabel@pengutronix.de, robh@kernel.org
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <177440394165.5403.17868576455504268400@localhost.localdomain>
> Quoting Yu-Chun Lin (2026-03-23 19:53:22)
> > diff --git
> > a/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > new file mode 100644
> > index 000000000000..6fabc2da3975
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/realtek,rtd1625-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Realtek RTD1625 Clock & Reset Controller
> > +
> > +maintainers:
> > + - Yu-Chun Lin <eleanor.lin@realtek.com>
> > +
> > +description: |
> > + The Realtek RTD1625 Clock Controller manages and distributes clock
> > + signals to various controllers and implements a Reset Controller
> > +for the
> > + SoC peripherals.
> > +
> > + Clocks and resets are referenced by unique identifiers, which are
> > + defined as preprocessor macros in
> > + include/dt-bindings/clock/realtek,rtd1625-clk.h and
> include/dt-bindings/reset/realtek,rtd1625.h.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - realtek,rtd1625-crt-clk
> > + - realtek,rtd1625-iso-clk
> > + - realtek,rtd1625-iso-s-clk
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + "#clock-cells":
> > + const: 1
> > +
> > + "#reset-cells":
> > + const: 1
>
> Are there any input clks for the clk tree?
>
We don't dynamically calculate frequencies based on an input clock.
Since all of our current SoCs use a fixed 27MHz oscillator, we use
predefined lookup tables in the driver for the target frequencies instead.
Nevertheless, to properly describe the hardware layout, I will add the clock
properties in the bindings and DTS in v6.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#clock-cells"
> > + - "#reset-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + clock-controller@98000000 {
> > + compatible = "realtek,rtd1625-crt-clk";
> > + reg = <98000000 0x1000>;
>
> Should be 0x98000000 to match the unit address.
>
Ack.
Best Regards,
Yu-Chun
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
^ permalink raw reply
* Re: [PATCH v2 3/3] mailbox: mtk-cmdq: Remove unsued cmdq_get_shift_pa()
From: Jason-JH Lin (林睿祥) @ 2026-03-30 2:49 UTC (permalink / raw)
To: jassisinghbrar@gmail.com, AngeloGioacchino Del Regno
Cc: linux-media@vger.kernel.org,
Sirius Wang (王皓昱),
Moudy Ho (何宗原), mchehab@kernel.org,
Xiandong Wang (王先冬), nicolas@ndufresne.ca,
linux-kernel@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
linux-mediatek@lists.infradead.org, chunkuang.hu@kernel.org,
Paul-pl Chen (陳柏霖),
dri-devel@lists.freedesktop.org,
Singo Chang (張興國),
Nancy Lin (林欣螢), wenst@chromium.org,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <CABb+yY2cjMskJeXsn8+hZj2DcFs05yabHbSaGT5XSi0fn45zCQ@mail.gmail.com>
On Sun, 2026-03-29 at 11:03 -0500, Jassi Brar wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On Tue, Mar 24, 2026 at 11:05 PM Jason-JH Lin
> <jason-jh.lin@mediatek.com> wrote:
> >
> > Since the mailbox driver data can be obtained using
> > cmdq_get_mbox_priv()
> > and all CMDQ users have transitioned to cmdq_get_mbox_priv(),
> > cmdq_get_shift_pa() can be removed.
> >
> > Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
> > Reviewed-by: AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com>
> > ---
[snip]
> I think the simplest would be to take this with the other two
> predecessor patches.
> Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
>
Thank you Jassi!
Hi Angelo,
Could you please take this with this series?
[Series V2 3/4] Remove shift_pa from CMDQ jump functions
https://lore.kernel.org/all/20260325040239.2112517-1-jason-jh.lin@mediatek.com/
Thanks!
Regards,
Jason-JH Lin
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Add RK3562 serial aliases
From: 谢致邦 (XIE Zhibang) @ 2026-03-30 2:46 UTC (permalink / raw)
To: krzk
Cc: Yeking, conor+dt, devicetree, finley.xiao, heiko, kever.yang,
krzk+dt, linux-arm-kernel, linux-kernel, linux-rockchip, robh
In-Reply-To: <9b3ee9e9-d44d-49b1-81ac-9c3806dc0efb@kernel.org>
On Sat, Mar 28, 2026 at 04:08:57PM +0100, Krzysztof Kozlowski wrote:
> On 28/03/2026 14:05, 谢致邦 (XIE Zhibang) wrote:
> > This fixes the stdout-path in rk3562-evb2-v10.dts.
> >
> > Fixes: ceb6ef1ea900 ("arm64: dts: rockchip: Add RK3562 evb2 devicetree")
> > Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3562.dtsi | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3562.dtsi b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > index e4816aa3dae0..14e74e8ac7df 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > @@ -26,6 +26,16 @@ aliases {
> > gpio2 = &gpio2;
> > gpio3 = &gpio3;
> > gpio4 = &gpio4;
> > + serial0 = &uart0;
> > + serial1 = &uart1;
> > + serial2 = &uart2;
> > + serial3 = &uart3;
> > + serial4 = &uart4;
> > + serial5 = &uart5;
> > + serial6 = &uart6;
> > + serial7 = &uart7;
> > + serial8 = &uart8;
> > + serial9 = &uart9;
>
> UART aliases are properties of the boards, not SoC.
>
> Best regards,
> Krzysztof
So are you saying that we need to remove the serial aliases from files
like rk3308.dtsi, rk3328.dtsi, rk3368.dtsi, rk3399-base.dtsi,
rk356x-base.dtsi, rk3576.dtsi, rk3588-base.dtsi, and so on?
Kind regards,
XIE Zhibang
^ permalink raw reply
* [PATCH] media: mediatek: vcodec: free working buf in vdec_vp9_slice_setup_single()
From: Haoxiang Li @ 2026-03-30 2:11 UTC (permalink / raw)
To: tiffany.lin, andrew-ct.chen, yunfei.dong, mchehab, matthias.bgg,
angelogioacchino.delregno, hverkuil+cisco, laurent.pinchart,
p.zabel, benjamin.gaignard, xiaoyong.lu, mingjia.zhang
Cc: linux-media, linux-kernel, linux-arm-kernel, linux-mediatek,
Haoxiang Li, stable
Add an error path label in vdec_vp9_slice_setup_single()
and call vdec_vp9_slice_free_working_buffer() to free
working buffer.
Fixes: b0f407c19648 ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
---
.../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index cd1935014d76..b3ecb94bebb3 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -1811,14 +1811,16 @@ static int vdec_vp9_slice_setup_single(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_prob_buffer(instance, vsi);
if (ret)
- goto err;
+ goto alloc_err;
ret = vdec_vp9_slice_setup_tile_buffer(instance, vsi, bs);
if (ret)
- goto err;
+ goto alloc_err;
return 0;
+alloc_err:
+ vdec_vp9_slice_free_working_buffer(instance);
err:
return ret;
}
--
2.25.1
^ permalink raw reply related
* [PATCH] media: mediatek: vcodec: free working buf on error path in vdec_vp9_slice_setup_lat()
From: Haoxiang Li @ 2026-03-30 2:02 UTC (permalink / raw)
To: tiffany.lin, andrew-ct.chen, yunfei.dong, mchehab, matthias.bgg,
angelogioacchino.delregno, laurent.pinchart, hverkuil+cisco,
benjamin.gaignard, p.zabel, george.sun
Cc: linux-media, linux-kernel, linux-arm-kernel, linux-mediatek,
Haoxiang Li, stable
Add an error path label in vdec_vp9_slice_setup_lat()
and call vdec_vp9_slice_free_working_buffer() to free
working buffer to prevent potential memory leak.
Fixes: 5d418351ca8f ("media: mediatek: vcodec: support stateless VP9 decoding")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
---
.../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index cd1935014d76..3dadb5cc8876 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -1168,7 +1168,7 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_lat_buffer(instance, vsi, bs, lat_buf);
if (ret)
- goto err;
+ goto alloc_err;
vdec_vp9_slice_setup_seg_buffer(instance, vsi, &instance->seg[0]);
@@ -1176,14 +1176,16 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_prob_buffer(instance, vsi);
if (ret)
- goto err;
+ goto alloc_err;
ret = vdec_vp9_slice_setup_tile_buffer(instance, vsi, bs);
if (ret)
- goto err;
+ goto alloc_err;
return 0;
+alloc_err:
+ vdec_vp9_slice_free_working_buffer(instance);
err:
return ret;
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: Eric Biggers @ 2026-03-29 22:18 UTC (permalink / raw)
To: David Laight
Cc: Demian Shulhan, linux-crypto, linux-kernel, linux-arm-kernel,
ardb
In-Reply-To: <20260329225704.0eb82966@pumpkin>
On Sun, Mar 29, 2026 at 10:57:04PM +0100, David Laight wrote:
> Final thought:
> Is that allowing for the cost of kernel_fpu_begin()? - which I think only
> affects the first call.
> And the cost of the data-cache misses for the lookup table reads? - again
> worse for the first call.
I assume you mean kernel_neon_begin(). This is an arm64 patch. (I
encourage you to actually read the code. You seem to send a lot of
speculation-heavy comments without actually reading the code.)
Currently, the benchmark in crc_kunit just measures the throughput in a
loop (as has been discussed before). So no, it doesn't currently
capture the overhead of pulling code and data into cache. For NEON
register use it captures only the amortized overhead.
Note that using PMULL saves having to pull the table into memory, while
using the table is a bit less code and saves having to use kernel-mode
NEON. So both have their advantages and disadvantages.
This patch does fall back to the table for the last 'len & ~15' bytes,
which means the table may be needed anyway. That is not the optimal way
to do it, and it's something to address later when this is replaced with
something similar to x86's crc-pclmul-template.S.
- Eric
^ permalink raw reply
* [PATCH net-next] net: airoha: Fix typo in airoha_set_gdm2_loopback routine name
From: Lorenzo Bianconi @ 2026-03-29 22:03 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Rename airhoha_set_gdm2_loopback() in airoha_set_gdm2_loopback()
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 82e53c60f561f6314fbf201ba8bc8711e40edc68..2beba017e791d20f142e754edafcd402d8cc496f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1709,7 +1709,7 @@ static int airoha_dev_set_macaddr(struct net_device *dev, void *p)
return 0;
}
-static int airhoha_set_gdm2_loopback(struct airoha_gdm_port *port)
+static int airoha_set_gdm2_loopback(struct airoha_gdm_port *port)
{
struct airoha_eth *eth = port->qdma->eth;
u32 val, pse_port, chan, nbq;
@@ -1785,7 +1785,7 @@ static int airoha_dev_init(struct net_device *dev)
if (!eth->ports[1]) {
int err;
- err = airhoha_set_gdm2_loopback(port);
+ err = airoha_set_gdm2_loopback(port);
if (err)
return err;
}
---
base-commit: cf0d9080c6f795bc6be08babbffa29b62c06e9b0
change-id: 20260329-airoha_set_gdm2_loopback-fix-typo-ce5131054f56
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: David Laight @ 2026-03-29 21:57 UTC (permalink / raw)
To: Eric Biggers
Cc: Demian Shulhan, linux-crypto, linux-kernel, linux-arm-kernel,
ardb
In-Reply-To: <20260329203829.GA2746@quark>
On Sun, 29 Mar 2026 13:38:29 -0700
Eric Biggers <ebiggers@kernel.org> wrote:
> On Sun, Mar 29, 2026 at 07:43:38AM +0000, Demian Shulhan wrote:
> > Implement an optimized CRC64 (NVMe) algorithm for ARM64 using NEON
> > Polynomial Multiply Long (PMULL) instructions. The generic shift-and-XOR
> > software implementation is slow, which creates a bottleneck in NVMe and
> > other storage subsystems.
> >
> > The acceleration is implemented using C intrinsics (<arm_neon.h>) rather
> > than raw assembly for better readability and maintainability.
> >
> > Key highlights of this implementation:
> > - Uses 4KB chunking inside scoped_ksimd() to avoid preemption latency
> > spikes on large buffers.
> > - Pre-calculates and loads fold constants via vld1q_u64() to minimize
> > register spilling.
> > - Benchmarks show the break-even point against the generic implementation
> > is around 128 bytes. The PMULL path is enabled only for len >= 128.
Final thought:
Is that allowing for the cost of kernel_fpu_begin()? - which I think only
affects the first call.
And the cost of the data-cache misses for the lookup table reads? - again
worse for the first call.
David
> >
> > Performance results (kunit crc_benchmark on Cortex-A72):
> > - Generic (len=4096): ~268 MB/s
> > - PMULL (len=4096): ~1556 MB/s (nearly 6x improvement)
> >
> > Signed-off-by: Demian Shulhan <demyansh@gmail.com>
>
> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=crc-next
>
> Thanks!
>
> - Eric
>
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: gemini: Rename power controller node to gemini-poweroff
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260329205151.15161-1-khushalchitturi@gmail.com>
Update the node name for the Cortina Gemini power controller from
power-controller to gemini-poweroff since node "power controller" is
reserved for power domain controller.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini/gemini.dtsi b/arch/arm/boot/dts/gemini/gemini.dtsi
index befe322bd7de..c524adadcf81 100644
--- a/arch/arm/boot/dts/gemini/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini/gemini.dtsi
@@ -228,7 +228,7 @@ intcon: interrupt-controller@48000000 {
#interrupt-cells = <2>;
};
- power-controller@4b000000 {
+ gemini-poweroff@4b000000 {
compatible = "cortina,gemini-power-controller";
reg = <0x4b000000 0x100>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260329205151.15161-1-khushalchitturi@gmail.com>
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v1 -> v2:
- Renamed the node from power-controller to gemini-poweroff to resolve dtschema warnings.
Note:
* This patch series is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
2 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..8fbe7e952b25
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gemini-poweroff@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] dt-bindings: power: reset: cortina: Convert to DT schema and rename node
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema and update corresponding dtsi file with new node name
---
Khushal Chitturi (2):
dt-bindings: power: reset: cortina,gemini-power-controller: convert to
DT schema
ARM: dts: gemini: Rename power controller node to gemini-poweroff
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
3 files changed, 43 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
--
2.53.0
^ permalink raw reply
* Re: [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: Eric Biggers @ 2026-03-29 20:38 UTC (permalink / raw)
To: Demian Shulhan; +Cc: linux-crypto, linux-kernel, linux-arm-kernel, ardb
In-Reply-To: <20260329074338.1053550-1-demyansh@gmail.com>
On Sun, Mar 29, 2026 at 07:43:38AM +0000, Demian Shulhan wrote:
> Implement an optimized CRC64 (NVMe) algorithm for ARM64 using NEON
> Polynomial Multiply Long (PMULL) instructions. The generic shift-and-XOR
> software implementation is slow, which creates a bottleneck in NVMe and
> other storage subsystems.
>
> The acceleration is implemented using C intrinsics (<arm_neon.h>) rather
> than raw assembly for better readability and maintainability.
>
> Key highlights of this implementation:
> - Uses 4KB chunking inside scoped_ksimd() to avoid preemption latency
> spikes on large buffers.
> - Pre-calculates and loads fold constants via vld1q_u64() to minimize
> register spilling.
> - Benchmarks show the break-even point against the generic implementation
> is around 128 bytes. The PMULL path is enabled only for len >= 128.
>
> Performance results (kunit crc_benchmark on Cortex-A72):
> - Generic (len=4096): ~268 MB/s
> - PMULL (len=4096): ~1556 MB/s (nearly 6x improvement)
>
> Signed-off-by: Demian Shulhan <demyansh@gmail.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=crc-next
Thanks!
- Eric
^ permalink raw reply
* AW: [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
From: Andreas Haarmann-Thiemann @ 2026-03-29 20:01 UTC (permalink / raw)
To: 'Linus Walleij'; +Cc: ulli.kroll, netdev, linux-arm-kernel
In-Reply-To: <CAD++jLmVPCL6p3jcdg1y_w=Zij6oVdWTvSmQFjWLn4yRJL4g=w@mail.gmail.com>
Hello Linus,
thank you for the confirmation!
Here is my Signed-off-by:
Signed-off-by: Andreas Haarmann-Thiemann <eitschman@nebelreich.de>
Please feel free to create the patch from the inline code.
Best regards,
Andreas Haarmann-Thiemann
-----Ursprüngliche Nachricht-----
Von: Linus Walleij <linusw@kernel.org>
Gesendet: Sonntag, 29. März 2026 20:54
An: Andreas Haarmann-Thiemann <eitschman@nebelreich.de>
Cc: ulli.kroll@googlemail.com; netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Betreff: Re: [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
Hi Andreas,
thanks for digging into this, I have wondered why this happens for a long time but I'm not the best net developer myself.
On Sun, Mar 29, 2026 at 12:05 PM Andreas Haarmann-Thiemann <eitschman@nebelreich.de> wrote:
> diff --git a/drivers/net/ethernet/cortina/gemini.c
> b/drivers/net/ethernet/cortina/gemini.c
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
>
> @@ -1491,6 +1491,10 @@ static int gmac_rx(struct napi_struct *napi, int budget)
> gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
> if (!gpage) {
> dev_err(geth->dev,
> "could not find mapping\n");
> + if (skb) {
> + napi_free_frags(&port->napi);
> + skb = NULL;
> + }
> port->stats.rx_dropped++;
> continue;
> }
This looks right to me, can you send a proper patch, or provide your Signed-off-by in this thread so I can create a patch from this inline code?
The kernel process requires a "certificate of origin" i.e. Signed-off-by, described a bit down in this document:
https://docs.kernel.org/process/submitting-patches.html
Yours,
Linus Walleij
^ permalink raw reply
* Re: [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
From: Linus Walleij @ 2026-03-29 18:54 UTC (permalink / raw)
To: Andreas Haarmann-Thiemann; +Cc: ulli.kroll, netdev, linux-arm-kernel
In-Reply-To: <006201dcbf63$84593aa0$8d0bafe0$@nebelreich.de>
Hi Andreas,
thanks for digging into this, I have wondered why this happens for a long
time but I'm not the best net developer myself.
On Sun, Mar 29, 2026 at 12:05 PM Andreas Haarmann-Thiemann
<eitschman@nebelreich.de> wrote:
> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
>
> @@ -1491,6 +1491,10 @@ static int gmac_rx(struct napi_struct *napi, int budget)
> gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
> if (!gpage) {
> dev_err(geth->dev, "could not find mapping\n");
> + if (skb) {
> + napi_free_frags(&port->napi);
> + skb = NULL;
> + }
> port->stats.rx_dropped++;
> continue;
> }
This looks right to me, can you send a proper patch, or provide your
Signed-off-by in this thread so I can create a patch from this inline code?
The kernel process requires a "certificate of origin" i.e. Signed-off-by,
described a bit down in this document:
https://docs.kernel.org/process/submitting-patches.html
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: stmmac: TSO fixes/cleanups
From: Russell King (Oracle) @ 2026-03-29 18:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <20260329111123.740bada9@kernel.org>
On Sun, Mar 29, 2026 at 11:11:23AM -0700, Jakub Kicinski wrote:
> On Sat, 28 Mar 2026 21:36:21 +0000 Russell King (Oracle) wrote:
> > Hot off the press from reading various sources of dwmac information,
> > this series attempts to fix the buggy hacks that were previously
> > merged, and clean up the code handling this.
>
> We have a limit of 15 outstanding patches per tree.
> Please follow the community guidelines.
I see that restriction was newly introduced back in January.
> While I have you - you have a significantly negative "reviewer score".
> You post much more than you review. Which should earn you extra 24h
> of delay in our system. I've been trying to ignore that and prioritize
> applying your patches but it'd be great if you could review a bit more.
Sorry, but given the effort that stmmac is taking, I don't have much
capacity to extend mental cycles elsewhere.
This two patch series wouldn't have exploded into ten (or maybe even
more) patches had someone not pointed out the problem with
suspend/resume interacting with disabling TSO... which prompted me to
look deeper and discover a multitude of other problems. Should I
instead ignore these bugs and not bother trying to fix this stuff?
Honestly, I'm getting tired of stmmac with it sucking lots of my time,
and I suspect you're getting tired of the constant stream of patches
for it - but the reason there's a constant stream is because there's
so much that's wrong or broken in this driver.
So either we let the driver rot, or... what?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] net: stmmac: dwmac-rk: Fix typo in comment
From: patchwork-bot+netdevbpf @ 2026-03-29 18:50 UTC (permalink / raw)
To: =?utf-8?b?6LCi6Ie06YKmIChYSUUgWmhpYmFuZykgPFlla2luZ0ByZWQ1NC5jb20+?=
Cc: linux-rockchip, Yeking, heiko, andrew+netdev, davem, edumazet,
kuba, pabeni, mcoquelin.stm32, alexandre.torgue, rmk+kernel,
linux-arm-kernel, netdev, linux-stm32, linux-kernel
In-Reply-To: <tencent_833D2AD6577F21CF38ED1C3FE8814EB4B308@qq.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 28 Mar 2026 13:43:31 +0000 you wrote:
> Correct the typo "rk3520" to "rk3528" in comment.
>
> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Here is the summary with links:
- net: stmmac: dwmac-rk: Fix typo in comment
https://git.kernel.org/netdev/net-next/c/30fcf28d83ee
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox