* RE: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Hongxing Zhu @ 2026-03-31 3:37 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Qiang Yu
In-Reply-To: <5nom7wnhrr57jvb6komumg3fjkbavsq5ecz2pd43rc5tsmnqev@ag6ld453s2lu>
> -----Original Message-----
> From: Manivannan Sadhasivam <mani@kernel.org>
> Sent: 2026年3月30日 18:19
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> lpieralisi@kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> bhelgaas@google.com; s.hauer@pengutronix.de; kernel@pengutronix.de;
> festevam@gmail.com; linux-pci@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev;
> linux-kernel@vger.kernel.org; stable@vger.kernel.org; Qiang Yu
> <qiang.yu@oss.qualcomm.com>
> Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> i.MX7D/i.MX8M
>
> On Mon, Mar 30, 2026 at 09:02:57AM +0000, Hongxing Zhu wrote:
> > > -----Original Message-----
> > > From: Manivannan Sadhasivam <mani@kernel.org>
> > > Sent: 2026年3月30日 15:23
> > > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > > Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> > > lpieralisi@kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> > > bhelgaas@google.com; s.hauer@pengutronix.de;
> kernel@pengutronix.de;
> > > festevam@gmail.com; linux-pci@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org;
> > > imx@lists.linux.dev; linux-kernel@vger.kernel.org;
> > > stable@vger.kernel.org; Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> > > i.MX7D/i.MX8M
> > >
> > > + Qiang
> > >
> > > On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > > > The MSI trigger mechanism for endpoint devices connected to
> > > > i.MX7D, i.MX8MM, and i.MX8MQ PCIe root complex ports depends on
> > > > the MSI capability register settings in the root complex. Removing
> > > > the MSI capability breaks MSI functionality for these endpoints.
> > > >
> > >
> > > What is the relation between Root Port MSI and endpoint MSI?
> > > Endpoint MSIs should be routed to the platform MSI controller (DWC
> > > i.MSI-RX or External like
> > > GIC-ITS) independent of the Root Port MSI state.
> > Hi Mani:
> > Thank for your kindly concern.
> > The MSI controller (DWC i.MSI-RX) on i.MX7D, i.MX8MM, and i.MX8MQ
> > platforms requires the RC's MSI capability to remain enabled. Removing
> > it breaks MSI routing from endpoints to the platform MSI controller.
> >
>
> I understand that MSI is broken on your hardware, but I was trying to
> understand 'why' specifically. Because, Root Port MSI capability doesn't have
> anything to do with the endpoint MSIs. And since you mentioned that this
> issue happens only on one platform, could be that the hardware designers
> have mistakenly wired the Root Port's 'MSI Enable' to iMSI-RX's enable signal
> or something similar?
Yes, that makes sense. Based on the behavior we're seeing, it does appear to
be a hardware wiring issue specific to these platforms, possibly with the Root
Port's MSI Enable incorrectly connected to the iMSI-RX enable signal.
>
> If so, we can introduce a flag 'dw_pcie_rp::keep_rp_msi_en' or something
> similar, set it for affected SoCs and skip the capability removal in
> pcie-designware-host.c
Good idea! I'll implement this approach with the 'dw_pcie_rp::keep_rp_msi_en'
flag and skip the capability removal for affected SoCs in pcie-designware-host.c.
Thanks for the suggestion!
Best Regards
Richard Zhu
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 06/30] KVM: arm64: Extract page table mapping in user_mem_abort()
From: Anshuman Khandual @ 2026-03-31 3:45 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-7-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Extract the code responsible for locking the KVM MMU and mapping the PFN
> into the stage-2 page tables into a new helper, kvm_s2_fault_map().
>
> This helper manages the kvm_fault_lock, checks for MMU invalidation
> retries, attempts to adjust for transparent huge pages (THP), handles
> MTE sanitization if needed, and finally maps or relaxes permissions on
> the stage-2 entries.
>
> With this change, the main user_mem_abort() function is now a sequential
> dispatcher that delegates to specialized helper functions.
>
> 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 | 128 +++++++++++++++++++++++--------------------
> 1 file changed, 68 insertions(+), 60 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d1ffdce18631a..164f1160ea33d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1892,68 +1892,13 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> return 0;
> }
>
> -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_map(struct kvm_s2_fault *fault, void *memcache)
> {
> - 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 *kvm = fault->vcpu->kvm;
> struct kvm_pgtable *pgt;
> + int ret;
> 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;
> -
> - ret = kvm_s2_fault_compute_prot(fault);
> - if (ret == 1) {
> - ret = 1; /* fault injected */
> - goto out_put_page;
> - }
> - if (ret)
> - goto out_put_page;
> -
> kvm_fault_lock(kvm);
> pgt = fault->vcpu->arch.hw_mmu->pgt;
> if (mmu_invalidate_retry(kvm, fault->mmu_seq)) {
> @@ -2001,8 +1946,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * PTE, which will be preserved.
> */
> fault->prot &= ~KVM_NV_GUEST_MAP_SZ;
> - ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault->fault_ipa, fault->prot,
> - flags);
> + 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->fault_ipa, fault->vma_pagesize,
> __pfn_to_phys(fault->pfn), fault->prot,
> @@ -2018,6 +1963,69 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> mark_page_dirty_in_slot(kvm, fault->memslot, fault->gfn);
>
> return ret != -EAGAIN ? ret : 0;
> +}
> +
> +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;
> + void *memcache;
> +
> + 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;
> +
> + ret = kvm_s2_fault_compute_prot(fault);
> + if (ret == 1) {
> + ret = 1; /* fault injected */
> + goto out_put_page;
> + }
> + if (ret)
> + goto out_put_page;
> +
> + ret = kvm_s2_fault_map(fault, memcache);
> + return ret;
>
> out_put_page:
> kvm_release_page_unused(fault->page);
^ permalink raw reply
* Re: [PATCH v2 07/30] KVM: arm64: Simplify nested VMA shift calculation
From: Anshuman Khandual @ 2026-03-31 3:56 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-8-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> In the kvm_s2_resolve_vma_size() helper, the local variable vma_pagesize
> is calculated from vma_shift, only to be used to bound the vma_pagesize
> by max_map_size and subsequently convert it back to a shift via __ffs().
>
> Because vma_pagesize and max_map_size are both powers of two, we can
> simplify the logic by omitting vma_pagesize entirely and bounding the
> vma_shift directly using the shift of max_map_size. This achieves the
> same result while keeping the size-to-shift conversion out of the helper
> logic.
>
> 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 | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 164f1160ea33d..5572b127f8663 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1646,7 +1646,6 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> bool *force_pte, phys_addr_t *ipa)
> {
> short vma_shift;
> - long vma_pagesize;
>
> if (*force_pte)
> vma_shift = PAGE_SHIFT;
> @@ -1677,8 +1676,6 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> WARN_ONCE(1, "Unknown vma_shift %d", vma_shift);
> }
>
> - vma_pagesize = 1UL << vma_shift;
> -
> if (nested) {
> unsigned long max_map_size;
>
> @@ -1703,8 +1700,7 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> 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);
> + vma_shift = min_t(short, vma_shift, __ffs(max_map_size));
> }
>
> return vma_shift;
^ permalink raw reply
* Re: [PATCH v2 08/30] KVM: arm64: Remove redundant state variables from struct kvm_s2_fault
From: Anshuman Khandual @ 2026-03-31 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-9-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Remove redundant variables vma_shift and vfio_allow_any_uc from struct
> kvm_s2_fault as they are easily derived or checked when needed.
> > 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 | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 5572b127f8663..1b991300735be 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1721,10 +1721,8 @@ struct kvm_s2_fault {
> 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;
> @@ -1749,9 +1747,9 @@ static int kvm_s2_fault_get_vma_info(struct kvm_s2_fault *fault)
> return -EFAULT;
> }
>
> - 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;
> + fault->vma_pagesize = 1UL << kvm_s2_resolve_vma_size(vma, fault->hva, fault->memslot,
> + fault->nested, &fault->force_pte,
> + &fault->ipa);
>
> /*
> * Both the canonical IPA and fault IPA must be aligned to the
> @@ -1764,8 +1762,6 @@ static int kvm_s2_fault_get_vma_info(struct kvm_s2_fault *fault)
> fault->gfn = fault->ipa >> PAGE_SHIFT;
> fault->mte_allowed = kvm_vma_mte_allowed(vma);
>
> - fault->vfio_allow_any_uc = vma->vm_flags & VM_ALLOW_ANY_UNCACHED;
> -
> fault->vm_flags = vma->vm_flags;
>
> fault->is_vma_cacheable = kvm_vma_is_cacheable(vma);
> @@ -1796,7 +1792,7 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> 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);
> + kvm_send_hwpoison_signal(fault->hva, __ffs(fault->vma_pagesize));
> return 0;
> }
> if (is_error_noslot_pfn(fault->pfn))
> @@ -1874,7 +1870,7 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> fault->prot |= KVM_PGTABLE_PROT_X;
>
> if (fault->s2_force_noncacheable) {
> - if (fault->vfio_allow_any_uc)
> + if (fault->vm_flags & VM_ALLOW_ANY_UNCACHED)
> fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> else
> fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> @@ -1978,7 +1974,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t 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;
^ permalink raw reply
* Re: [PATCH v2 09/30] KVM: arm64: Simplify return logic in user_mem_abort()
From: Anshuman Khandual @ 2026-03-31 4:32 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-10-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> With the refactoring done, the final return block of user_mem_abort()
> can be tidied up a bit more.
>
> Clean up the trailing edge by dropping the unnecessary assignment,
> collapsing the return evaluation for kvm_s2_fault_compute_prot(), and
> tail calling kvm_s2_fault_map() directly.
>
> 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 | 17 ++++-------------
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1b991300735be..e77b0b60697f6 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2005,22 +2005,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> if (ret != 1)
> return ret;
>
> - ret = 0;
> -
> ret = kvm_s2_fault_compute_prot(fault);
> - if (ret == 1) {
> - ret = 1; /* fault injected */
> - goto out_put_page;
> + if (ret) {
> + kvm_release_page_unused(fault->page);
> + return ret;
> }
> - if (ret)
> - goto out_put_page;
>
> - ret = kvm_s2_fault_map(fault, memcache);
> - return ret;
> -
> -out_put_page:
> - kvm_release_page_unused(fault->page);
> - return ret;
> + return kvm_s2_fault_map(fault, memcache);
> }
>
> /* Resolve the access fault by making the page young again. */
^ permalink raw reply
* Re: [PATCH v2 10/30] KVM: arm64: Initialize struct kvm_s2_fault completely at declaration
From: Anshuman Khandual @ 2026-03-31 5:43 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-11-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Simplify the initialization of struct kvm_s2_fault in user_mem_abort().
>
> Instead of partially initializing the struct via designated initializers
> and then sequentially assigning the remaining fields (like write_fault
> and topup_memcache) further down the function, evaluate those
> dependencies upfront.
>
> This allows the entire struct to be fully initialized at declaration. It
> also eliminates the need for the intermediate fault_data variable and
> its associated fault pointer, reducing boilerplate.
>
> 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 | 34 ++++++++++++++++------------------
> 1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index e77b0b60697f6..2b85daaa4426b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1962,8 +1962,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_memory_slot *memslot, unsigned long hva,
> bool fault_is_perm)
> {
> - int ret = 0;
> - struct kvm_s2_fault fault_data = {
> + bool write_fault = kvm_is_write_fault(vcpu);
> + bool logging_active = memslot_is_logging(memslot);
> + struct kvm_s2_fault fault = {
> .vcpu = vcpu,
> .fault_ipa = fault_ipa,
> .nested = nested,
> @@ -1971,19 +1972,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> .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,
> + .logging_active = logging_active,
> + .force_pte = logging_active,
> .prot = KVM_PGTABLE_PROT_R,
> + .fault_granule = fault_is_perm ? kvm_vcpu_trap_get_perm_fault_granule(vcpu) : 0,
> + .write_fault = write_fault,
> + .exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu),
> + .topup_memcache = !fault_is_perm || (logging_active && write_fault),
> };
> - struct kvm_s2_fault *fault = &fault_data;
> void *memcache;
> + int ret;
>
> - 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);
> + VM_WARN_ON_ONCE(fault.write_fault && fault.exec_fault);
>
> /*
> * Permission faults just need to update the existing leaf entry,
> @@ -1991,9 +1991,7 @@ 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.
> */
> - fault->topup_memcache = !fault->fault_is_perm ||
> - (fault->logging_active && fault->write_fault);
> - ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache);
> + ret = prepare_mmu_memcache(vcpu, fault.topup_memcache, &memcache);
> if (ret)
> return ret;
>
> @@ -2001,17 +1999,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * 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);
> + ret = kvm_s2_fault_pin_pfn(&fault);
> if (ret != 1)
> return ret;
>
> - ret = kvm_s2_fault_compute_prot(fault);
> + ret = kvm_s2_fault_compute_prot(&fault);
> if (ret) {
> - kvm_release_page_unused(fault->page);
> + kvm_release_page_unused(fault.page);
> return ret;
> }
>
> - return kvm_s2_fault_map(fault, memcache);
> + return kvm_s2_fault_map(&fault, memcache);
> }
>
> /* Resolve the access fault by making the page young again. */
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Andy Shevchenko @ 2026-03-31 6:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <acruxMNdnUlyRHiy@google.com>
On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
...
> > > -static void __exit software_node_exit(void)
> > > -{
> > > - ida_destroy(&swnode_root_ids);
> > > - kset_unregister(swnode_kset);
> > > }
> > > -__exitcall(software_node_exit);
> >
> > Why? What's wrong with the __exitcall?
>
> It's dead code. Always was, always will be.
>
> Maybe split in a separate patch, but I sometimes feel the idea of "one
> change" is taken to extreme and adds to both developer's and maintainers
> burden by needing to keep track of extra patches.
Why does __exitcall() exist then? It's also used in other places.
I think it's generally good to have a possibility to clean up
after run.
A bit of archaeology:
The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
Then somehow spread a bit (but not much).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive
From: Vishnu Pajjuri @ 2026-03-31 6:31 UTC (permalink / raw)
To: Marc Zyngier
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Christoffer Dall, Mark Brown, kvm, linux-arm-kernel,
kvmarm
In-Reply-To: <878qb9cxzr.wl-maz@kernel.org>
Hi Marc,
Many thanks for your reply.
On 30-03-2026 17:47, Marc Zyngier wrote:
> On Mon, 30 Mar 2026 12:51:51 +0100,
> Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
>>
>> Hi Fuad Tabba,
>
> To be brutally honest, I doubt Fuad really cares about NV,
I see Tested-by: fuad Tabba on this patch so tried to reach out him.
>
>> I'm trying to run nested VMs on Ampere platforms after this patch
>> series(v6.19+) but nested VMs are not booting and triggering soft
>> lockups on L0 and L0 hang. But just before this patch I could able to
>> successfully boot the Nested VMs.
>
> So the host dies? There isn't much here that interacts with the host
> at all. Worse case, the L1 dies by not making progress.
Initially L1 become unresponsive then L0 becomes unresponsive, soft
lockups and L0 hang.
>
>>
>> I bisected the failure to a single commit which is this patch which is
>> causing the issue.
>>
>> I would like to understand from you that did you observed anything
>> like that?
>
> No. If I had, I wouldn't have merged the series.
>
>>
>> Were you able to boot Nested VMs successfully after v6.19+?
>
> I boot L3s every day.
Do you mean L2s or L3s on top of L2s?
I running L1 and L2 using latest QEMU, do you use QEMU or kvmtool run L1
and L2 in your regression tests?
>
>> LOG:
>> [ 164.647367] Call trace:
>> [ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P)
>> [ 164.647372] smp_call_function_many+0x20/0x40
>> [ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8
>> [ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8
>> [ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0
>> [ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400
>> [ 164.647386] kvm_vm_ioctl+0x7b8/0xc88
>> [ 164.647389] __arm64_sys_ioctl+0xb4/0x118
>> [ 164.647393] invoke_syscall+0x6c/0x100
>> [ 164.647397] el0_svc_common.constprop.0+0x48/0xf0
>> [ 164.647398] do_el0_svc+0x24/0x38
>> [ 164.647400] el0_svc+0x3c/0x170
>> [ 164.647403] el0t_64_sync_handler+0xa0/0xe8
>> [ 164.647405] el0t_64_sync+0x1b0/0x1b8
>
> This trace is about interrupt injection from userspace, not
> deactivation of a HW interrupt.
> None of that makes much sense.
Although this behavior is puzzling, it matches the trace I typically
observe on L0. After reverting the patch, I was able to boot L2 guests
successfully.
Regards,
-Vishnu
>
> M.
>
^ permalink raw reply
* Re: [PATCH v2 11/30] KVM: arm64: Optimize early exit checks in kvm_s2_fault_pin_pfn()
From: Anshuman Khandual @ 2026-03-31 6:35 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-12-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Optimize the early exit checks in kvm_s2_fault_pin_pfn by grouping all
> error responses under the generic is_error_noslot_pfn check first,
> avoiding unnecessary branches in the hot path.
>
> 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 | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 2b85daaa4426b..0c71e3a9af8b0 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1791,12 +1791,13 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> 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, __ffs(fault->vma_pagesize));
> - return 0;
> - }
> - if (is_error_noslot_pfn(fault->pfn))
> + if (unlikely(is_error_noslot_pfn(fault->pfn))) {
> + if (fault->pfn == KVM_PFN_ERR_HWPOISON) {
> + kvm_send_hwpoison_signal(fault->hva, __ffs(fault->vma_pagesize));
> + return 0;
> + }
> return -EFAULT;
> + }
>
> return 1;
> }
^ permalink raw reply
* Re: [PATCH v2] raid6: arm64: add SVE optimized implementation for syndrome generation
From: Christoph Hellwig @ 2026-03-31 6:36 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Demian Shulhan, Mark Rutland, Christoph Hellwig, Song Liu,
Yu Kuai, Will Deacon, Catalin Marinas, Mark Brown,
linux-arm-kernel, robin.murphy, Li Nan, linux-raid, linux-kernel
In-Reply-To: <9a12e043-8200-4650-bfe2-cbece57a4f87@app.fastmail.com>
On Mon, Mar 30, 2026 at 06:39:49PM +0200, Ard Biesheuvel wrote:
> I think the results are impressive, but I'd like to better understand
> its implications on a real-world scenario. Is this code only a
> bottleneck when rebuilding an array?
The syndrome generation is run every time you write data to a RAID6
array, and if you do partial stripe writes it (or rather the XOR
variant) is run twice. So this is the most performance critical
path for writing to RAID6.
Rebuild usually runs totally different code, but can end up here as well
when both parity disks are lost.
> > 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.
>
> Does this mean the kernel benchmark is no longer fit for purpose? If
> it cannot distinguish between implementations that differ in performance
> by a factor of 2, I don't think we can rely on it to pick the optimal one.
It is not good, and we should either fix it or run more than one.
The current setup is not really representative of real-life array.
It also leads to wrong selections on x86, but only at the which unroll
level to pick level, and only for minor differences so far. I plan
to add this to the next version of the raid6 lib patches.
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Manivannan Sadhasivam @ 2026-03-31 6:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Manivannan Sadhasivam, mark.rutland, lpieralisi, bjorn.andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, Konrad Dybcio,
Konrad Dybcio, Sudeep Holla
In-Reply-To: <acrdFfk8al80dynq@baldur>
On Mon, Mar 30, 2026 at 03:48:05PM -0500, Bjorn Andersson wrote:
> On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
> > From: Konrad Dybcio <konradybcio@kernel.org>
> >
> > PSCI specification defines the SYSTEM_SUSPEND feature which enables the
> > firmware to implement the suspend to RAM (S2RAM) functionality by
> > transitioning the system to a deeper low power state. When the system
> > enters such state, the power to the peripheral devices might be removed.
>
> What is the actual extent of "peripheral devices" in this definition?
>
All devices except the ones backing volatile memory (DDR).
> > So
> > the respective device drivers must prepare for the possible removal of the
> > power by performing actions such as shutting down or resetting the device
> > in their system suspend callbacks.
> >
>
> Our typical interpretation of this state is that IP-blocks might be
> non-functional during this time, but typically some state is retained.
>
> Will the acceptance of this patch result in that we in the Qualcomm case
> should start accepting/writing patches that implement save/restore of
> state that is generally retained throughout the drivers - in the name of
> "power might be removed"?
>
From the PSCI spec perspective, the underlying implementation of the
SYSTEM_SUSPEND is implementation defined. So whether the vendor firmware retains
the state or drops it completely, is out of the scope for PSCI. That's why
*assuming* that the devices will loose power is the best possible approach.
For sure, assuming that the power will be lost always will result in some
overhead with drivers saving and restoring the context unnecessarily if the
power if retained. But I can't think of any other way to make the driver work
across all firmware implementations.
> > The Linux PM framework allows the platform drivers to convey this info to
> > device drivers by calling the pm_set_suspend_via_firmware() and
> > pm_set_resume_via_firmware() APIs.
> >
> > Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
> > mentioned APIs in the psci_system_suspend_begin() and
> > psci_system_suspend_enter() callbacks.
> >
>
> With the right interpretation of what this means for us, I think this
> patch looks good - but as we've discussed, I'm a bit worried about how
> to deal with the alternative interpretations.
>
Just for the sake of clarity to others, 'alternative interpretations' is
referring to Qcom DeepSleep firmware implementation, which cuts power to almost
all components except DDR with no wakeup source other than PMIC.
> Specifically, if we fully adopt "power might be removed", we should to
> take actions which will prevent a typical Qualcomm system from waking up
> from sleep again.
>
I think for wakeup, the driver should just save the device context and call
enable_irq_wake() if the user has configured the device as a wakeup source and
assume that the device will wakeup the system from suspend/sleep.
The underlying firmware should honor the wakeup and not cut the power to the
devices. But if it does, then wakeup will be broken anyway.
So from Qcom drivers perspective:
1. They should save and restore the context if those drivers are going to be
used in both PSCI SYSTEM_SUSPEND (power retained) and DeepSleep (power lost)
firmware implementations.
2. If the user has configured wakeup, they should enable wakeup using
enable_irq_wake() during suspend. On PSCI SYSTEM_SUSPEND implementations, wakeup
should just work, but on DeepSleep, it may not if the power is cut off
completely. But that's the limitation on those platforms and the OS policy
should ensure that wakeup is not configured for devices.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Jie Zhan @ 2026-03-31 6:43 UTC (permalink / raw)
To: Yaxiong Tian, cw00.choi, myungjoo.ham, kyungmin.park
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <94f5b6ff-f610-44f6-90e4-2e538b4f99c9@kylinos.cn>
On 3/31/2026 9:30 AM, Yaxiong Tian wrote:
>
> 在 2026/3/30 14:29, Jie Zhan 写道:
>>
>> On 3/27/2026 10:06 AM, Yaxiong Tian wrote:
>>> 在 2026/3/26 21:14, Jie Zhan 写道:
>>>> On 3/26/2026 8:34 PM, Jie Zhan wrote:
>>>>> When compiled as a kernel module, the governor module can be dynamically
>>>>> inserted or removed. 'devfreq->governor' would become NULL if the governor
>>>>> module is removed when it's in use, and NULL pointer dereference would be
>>>>> triggered. A similar issue was also reported in [1].
>>>>>
>>>>> To address this issue:
>>>>>
>>>>> Patch 1-5 rework mutex, factor out a common governor setting function, and
>>>>> clean up some unreachable code.
>>>>>
>>>>> Patch 6-8 prevent a governor module in use from being removed (except for
>>>>> force unload) by getting/putting a refcount of the governor's module when
>>>>> switching governors.
>>>>>
>>>>> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
>>>>> when a governor module in use is force unloaded.
>>>>>
>>>>> Note that this series is based on [1] or devfreq-next, otherwise code
>>> Sorry, please ignore the "remember to CC me on the patches." in my previous email.
>>>
>>> In my opinion, it would be better to prioritize the FIX first before proceeding with the lock mechanism optimizations and other work. This would make it easier to backport the patches to lower-version kernels. I noticed the patch is already in the devfreq-testing branch. I hope the FIX work can be moved forward smoothly to resolve the null pointer and other bugs. Thank you!
>> Hi Yaxiong,
>>
>> I don't think this issue is urgent because it can only possibly happen when
>> governors are built as loadable modules, which is typically used for
>> development rather than production.
> No, loading/unloading modules is also a user operational requirement, not just for development.
>
>>
>> For downstream kernels, feel free to go ahead with quick fixes. For the
>> upstream kernel, however, I'd prefer to make the devfreq core clean and
>> sensible.
>
> I don't think code cleanup should take priority over bug fixes, especially when you already know there's an issue with the functionality. In fact, the version users are running is not the upstream version, but rather individual stable releases.
The point is to do the bugfix in a different way rather than cleanups.
>
> Most users don't have the time or energy to research and fix kernel issues themselves; they rely on upstream community patches most of the time.
>
> By the way, although your patch subject says "FIX", I don't see any fix tag.
>
>>
>> Your approach is to prevent kernel panics when unloading governor modules
>> before changing governors.
>>
>> This patchset achieves that, and additionally let userspace get a friendly
>> warning when trying to remove a governor module in use, e.g.
>> "rmmod: ERROR: Module governor_performance is in use".
>> This requires using the module refcount stuff, and brings out a set of
>> cleanups and refactoring. BTW, cpufreq implements a similar mechanism like
>> this.
>>
>> I may carry your fourth patch that changes the return code of
>> governor_show() in v2 and address some Sashiko review comments along the
>> way.
>>
>> Please let me know if this works for you?
> So I don't approve of this. Maybe you should ask for others' opinions, such as Chanwoo Choi.
>
No problem. I see your point.
I'll take a closer look at your version and see if that works.
The module owner refcount related stuff can be rebased later if needed.
Thanks,
Jie
>>
>> Regards,
>> Jie
>>>
>>>
>>>> sorry, based on [2] or devfreq-next
>>>>> would conflict.
>>>>>
>>>>> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
>>>>> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Krzysztof Kozlowski @ 2026-03-31 6:47 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel, linux-i2c,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
In-Reply-To: <20260330-upstream_i2c-v28-2-17bdae39c5cb@aspeedtech.com>
On Mon, Mar 30, 2026 at 04:21:47PM +0800, Ryan Chen wrote:
> Add aspeed,enable-dma boolean property to indicate that DMA is
> available for transfers on this I2C bus.
>
> Also add the aspeed,global-regs phandle to reference the AST2600
> global registers syscon node, containing the SoC-common I2C register
> set.
>
> These properties apply only to the AST2600 binding. Legacy DTs remain
> unchanged.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v28:
> - update commit message correspond with aspeed,enable-dma.
> - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> description.
> - Fix aspeed,enable-dma description to reflect hardware capability rather
> than software behavior
> Changes in v27:
> - change aspeed,transfer-mode to aspeed,enable-dma.
> ---
> .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> index de2c359037da..67b23d1a4cec 100644
> --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> @@ -37,6 +37,16 @@ properties:
> resets:
> maxItems: 1
>
> + aspeed,enable-dma:
> + type: boolean
> + description: Indicates this I2C controller instance has DMA capability.
Compatible implies that "I2C controller instance has DMA capability", no?
How two same devices, with exactly the same or compatible programming
model can have difference in the programming model for DMA (one lacks
it)?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
From: Christoph Hellwig @ 2026-03-31 6:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto, linux-arm-kernel, Demian Shulhan, Eric Biggers
In-Reply-To: <20260330144630.33026-12-ardb@kernel.org>
> depends on CRC64 && CRC_OPTIMIZATIONS
> + default y if ARM && KERNEL_MODE_NEON && !(CPU_BIG_ENDIAN && CC_IS_CLANG)
It would be useful to throw in a comment here why it is disabled for
big-endian on clang.
> +#define crc64_be_arch crc64_be_generic
> +
> +static inline u64 crc64_nvme_arch(u64 crc, const u8 *p, size_t len)
> +{
> + if (len >= 128 && static_branch_likely(&have_pmull) &&
> + likely(may_use_simd())) {
> + do {
> + size_t chunk = min_t(size_t, len & ~15, SZ_4K);
> +
> + scoped_ksimd()
> + crc = crc64_nvme_arm64_c(crc, p, chunk);
> +
> + p += chunk;
> + len -= chunk;
> + } while (len >= 128);
> + }
From reading the earlier patches, I'll assume arm SIMD code is
non-preemptable and thus you want the chunking here? Maybe add
a little comment explaining that?
^ permalink raw reply
* Re: RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace
From: bigeasy @ 2026-03-31 6:52 UTC (permalink / raw)
To: Maninder Singh
Cc: Russell King (Oracle), peterz@infradead.org, kees@kernel.org,
ardb@kernel.org, keithpac@amazon.com, linusw@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260309055328epcms5p56d16f6cb1e3a5295987c935f35be1d2e@epcms5p5>
On 2026-03-09 11:23:28 [+0530], Maninder Singh wrote:
> Hi,
Hi,
> >"otherwise if someone calls show_stack() for task" ... and the stack
> >trace given stops at show_stack() and doesn't show the "someone".
> >
> >I'd like to know _how_ this happens, and why ARM64 and now 32-bit ARM
> >are different from x86.
>
> I tried to simulate same thing on x86_64, it is also crashing.
>
> Just a dummy code to save task_struct to reproduce the race:
>
> + rcu_read_lock();
> + for_each_process(p) {
> + if (!strcmp(p->comm, "sleep")) {
> + check_task = p;
> + get_task_struct(p);
> + pr_emerg("get done for %s %d\n", p->comm, p->pid);
> + }
> + }
> + rcu_read_unlock();
>
> // in mean time here sleep binary will be exited.
>
> + show_stack(check_task, NULL, KERN_EMERG);
The task's stack is released on its final schedule() invocation.
Therefore holding task_struct does not hold the stack of the task if it
is separated out of task_struct and can be gone if the tasks quits.
Therefore holding a reference to the stack while accessing it, like
during a backtrace, makes sense and is required if the task is not
current.
Let me add this to my list and tackle it later today for x86. Then we
get probably Russell on board for ARM.
> //OOPs
Sebastian
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Dmitry Torokhov @ 2026-03-31 6:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <acto3TE1AR8iTzF0@ashevche-desk.local>
On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
>> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
>> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
>
>...
>
>> > > -static void __exit software_node_exit(void)
>> > > -{
>> > > - ida_destroy(&swnode_root_ids);
>> > > - kset_unregister(swnode_kset);
>> > > }
>> > > -__exitcall(software_node_exit);
>> >
>> > Why? What's wrong with the __exitcall?
>>
>> It's dead code. Always was, always will be.
>>
>> Maybe split in a separate patch, but I sometimes feel the idea of "one
>> change" is taken to extreme and adds to both developer's and maintainers
>> burden by needing to keep track of extra patches.
>
>Why does __exitcall() exist then? It's also used in other places.
>I think it's generally good to have a possibility to clean up
>after run.
>
The code section will be discarded when the kernel finishes booting so it only increases image size on disk.
>A bit of archaeology:
>
>The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
>Then somehow spread a bit (but not much).
>
And it shows how useful it is. Maybe it had some purpose a long time ago, but at present time this code will never be executed since it cannot be built as a module.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 12/30] KVM: arm64: Hoist MTE validation check out of MMU lock path
From: Anshuman Khandual @ 2026-03-31 6: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-13-maz@kernel.org>
On 27/03/26 5:06 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Simplify the non-cacheable attributes assignment by using a ternary
> operator. Additionally, hoist the MTE validation check (mte_allowed) out
> of kvm_s2_fault_map() and into kvm_s2_fault_compute_prot(). This allows
> us to fail faster and avoid acquiring the KVM MMU lock unnecessarily
> when the VMM introduces a disallowed VMA for an MTE-enabled guest.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/mmu.c | 28 ++++++++++++----------------
> 1 file changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 0c71e3a9af8b0..ee2a548999b1b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1870,18 +1870,21 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> if (fault->exec_fault)
> fault->prot |= KVM_PGTABLE_PROT_X;
>
> - if (fault->s2_force_noncacheable) {
> - if (fault->vm_flags & VM_ALLOW_ANY_UNCACHED)
> - fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> - else
> - fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> - } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> + if (fault->s2_force_noncacheable)
> + fault->prot |= (fault->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
> + KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
> + else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
> fault->prot |= KVM_PGTABLE_PROT_X;
> - }
Is not the existing code block bit more cleaner though ?
>
> if (fault->nested)
> adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
>
> + if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm)) {
> + /* Check the VMM hasn't introduced a new disallowed VMA */
> + if (!fault->mte_allowed)
> + return -EFAULT;
> + }
> +
> return 0;
> }
>
> @@ -1918,15 +1921,8 @@ static int kvm_s2_fault_map(struct kvm_s2_fault *fault, void *memcache)
> }
> }
>
> - if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm)) {
> - /* Check the VMM hasn't introduced a new disallowed VMA */
> - if (fault->mte_allowed) {
> - sanitise_mte_tags(kvm, fault->pfn, fault->vma_pagesize);
> - } else {
> - ret = -EFAULT;
> - goto out_unlock;
> - }
> - }
> + if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm))
> + sanitise_mte_tags(kvm, fault->pfn, fault->vma_pagesize);
>
> /*
> * Under the premise of getting a FSC_PERM fault, we just need to relax
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Krzysztof Kozlowski @ 2026-03-31 6:58 UTC (permalink / raw)
To: Jianhua Lin
Cc: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu
In-Reply-To: <20260331005458.24010-2-jianhua.lin@mediatek.com>
On Tue, Mar 31, 2026 at 08:54:56AM +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG decoder block found in the
> MediaTek MT8189 SoC.
>
> Compared to previous generation ICs, the MT8189 JPEG decoder requires
> 34-bit IOVA address space support and only needs a single clock
> ("jpgdec") instead of two. Therefore, it is added as a standalone
> compatible string without falling back to older SoCs.
>
> Update the binding schema to include the new compatible string and add
> an `allOf` block with conditional checks. This enforces the single clock
> requirement for MT8189 while preserving the two-clock requirement
> ("jpgdec-smi", "jpgdec") for older SoCs.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
> 1 file changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> index a4aacd3eb189..601fe05b73e7 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> @@ -15,10 +15,10 @@ description: |-
> properties:
> compatible:
> oneOf:
> - - items:
> - - enum:
> - - mediatek,mt8173-jpgdec
> - - mediatek,mt2701-jpgdec
> + - enum:
> + - mediatek,mt2701-jpgdec
> + - mediatek,mt8173-jpgdec
> + - mediatek,mt8189-jpgdec
> - items:
> - enum:
> - mediatek,mt7623-jpgdec
> @@ -32,13 +32,22 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> maxItems: 2
> - minItems: 2
>
> clock-names:
> - items:
> - - const: jpgdec-smi
> - - const: jpgdec
> + minItems: 1
> + maxItems: 2
Why jpgdec-smi alone is now valid? Drop these two.
> + oneOf:
> + - items:
> + - const: jpgdec
> + - items:
> + - const: jpgdec-smi
> + - const: jpgdec
> +
> + mediatek,larb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: a phandle to the smi_larb node.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-03-31 6:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: jk@codeconstruct.com.au, andriy.shevchenko@linux.intel.com,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Benjamin Herrenschmidt,
Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20260331-fanatic-certain-bustard-fb13bc@quoll>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> On Mon, Mar 30, 2026 at 04:21:47PM +0800, Ryan Chen wrote:
> > Add aspeed,enable-dma boolean property to indicate that DMA is
> > available for transfers on this I2C bus.
> >
> > Also add the aspeed,global-regs phandle to reference the AST2600
> > global registers syscon node, containing the SoC-common I2C register
> > set.
> >
> > These properties apply only to the AST2600 binding. Legacy DTs remain
> > unchanged.
> >
> > Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> > ---
> > Changes in v28:
> > - update commit message correspond with aspeed,enable-dma.
> > - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> > description.
> > - Fix aspeed,enable-dma description to reflect hardware capability rather
> > than software behavior
> > Changes in v27:
> > - change aspeed,transfer-mode to aspeed,enable-dma.
> > ---
> > .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 12
> ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > index de2c359037da..67b23d1a4cec 100644
> > --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > @@ -37,6 +37,16 @@ properties:
> > resets:
> > maxItems: 1
> >
> > + aspeed,enable-dma:
> > + type: boolean
> > + description: Indicates this I2C controller instance has DMA capability.
>
> Compatible implies that "I2C controller instance has DMA capability", no?
>
> How two same devices, with exactly the same or compatible programming
> model can have difference in the programming model for DMA (one lacks it)?
>
> Best regards,
> Krzysztof
Thanks your review.
All AST2600 I2C controller instances have DMA hardware.
I will remove the aspeed,enable-dma property and instead expose sysfs
attribute in driver to allow users to enable dma/buffer/byte.
^ permalink raw reply
* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Jeremy Kerr @ 2026-03-31 7:00 UTC (permalink / raw)
To: Ryan Chen, Krzysztof Kozlowski
Cc: andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <TY2PPF5CB9A1BE6F267C60EEC34B6A75400F253A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Hi Ryan,
> All AST2600 I2C controller instances have DMA hardware.
> I will remove the aspeed,enable-dma property and instead expose sysfs
> attribute in driver to allow users to enable dma/buffer/byte.
Sounds reasonable, but before you do so, how are you planning to manage
the allocation of DMA channels across multiple i2c peripherals?
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-2-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:35AM +0100, Luca Leonardo Scorcia wrote:
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Not really, this affects existing ABI and might make the child schema
being applied. Basically regulators node can be anything now.
This is definitely not a binding we want. The syntax for parent schema
when listing only compatibles is requiring this compatible. You cannot
have here whatever empty node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260330083429.359819-4-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:37AM +0100, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 74 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..24fbaef0e717
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
So that's a dead code / schema.
Try yourself if it works.
Your parent schema must reference this one for the regulators node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4] ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
From: Krzysztof Kozlowski @ 2026-03-31 7:05 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li,
shengjiu.wang, s.hauer, kernel, festevam, linux-sound, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331012450.1298115-1-chancel.liu@nxp.com>
On Tue, Mar 31, 2026 at 10:24:50AM +0900, Chancel Liu wrote:
> Currently this binding only lists i2s and dsp_b formats that are used
> by existing sound cards. However, DT bindings should describe the full
> hardware capabilities rather than only the formats of current usage.
>
> The SAI audio controller of i.MX audio sound card supports multiple DAI
> formats, including:
> - i2s
> - left_j
> - right_j
> - dsp_a
> - dsp_b
> - pdm
> - msb
> - lsb
>
> Complete the full list of formats supported by i.MX audio sound card to
> ensure the binding correctly describes hardware.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] ti,j721e-system-controller.yaml: Allow audio-refclk as clock-controller child
From: Krzysztof Kozlowski @ 2026-03-31 7:09 UTC (permalink / raw)
To: Moteen Shah
Cc: krzk+dt, robh, conor+dt, nm, vigneshr, kristo, devicetree,
linux-arm-kernel, linux-kernel, u-kumar1, gehariprasath,
y-abhilashchandra
In-Reply-To: <20260330094459.128648-2-m-shah@ti.com>
On Mon, Mar 30, 2026 at 03:14:58PM +0530, Moteen Shah wrote:
> The ti,j721e-system-controller binding currently only allows
> clock-controller@ child nodes to reference the ti,am654-ehrpwm-tbclk
> schema. However, the system controller on J721S2 also contains audio
J721S2 or AM62?
> reference clock controllers (ti,am62-audio-refclk) that use the same
> clock-controller@XXXX naming pattern.
>
> Hence, extend the clock-controller pattern to accept either ehrpwm-tbclk
> or audio-refclk schemas using a oneOf constraint.
>
> Signed-off-by: Moteen Shah <m-shah@ti.com>
> ---
> .../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> index f3bd0be3b279..d5d84a8f1257 100644
> --- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> +++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> @@ -53,9 +53,11 @@ patternProperties:
>
> "^clock-controller@[0-9a-f]+$":
> type: object
> - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
> + oneOf:
> + - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
> + - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
Alphanumerical order.
There is no ti,am62 in the top level compatibles, so why am62 is here?
Top level has j721s2 but this ti,am62-audio-refclk.yaml only am62.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-03-31 7:09 UTC (permalink / raw)
To: Jeremy Kerr, Krzysztof Kozlowski
Cc: andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <09cbc12bea5707f794e139ea1bfafac82c2d2c12.camel@codeconstruct.com.au>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> Hi Ryan,
>
> > All AST2600 I2C controller instances have DMA hardware.
> > I will remove the aspeed,enable-dma property and instead expose sysfs
> > attribute in driver to allow users to enable dma/buffer/byte.
>
> Sounds reasonable, but before you do so, how are you planning to manage the
> allocation of DMA channels across multiple i2c peripherals?
>
The AST2600 I2C hardware has only one can use DMA at a time.
To avoid the complexity of managing DMA channel contention,
I plan to use buffer mode by default for all controllers, which still provides
better performance than byte mode without requiring DMA channel allocation.
^ 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