* [PATCH v3 11/11] iommu/arm-smmu-v3: Block ATS upon an ATC invalidation timeout
From: Nicolin Chen @ 2026-04-16 23:28 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <cover.1776381841.git.nicolinc@nvidia.com>
Currently, when GERROR_CMDQ_ERR occurs, the arm_smmu_cmdq_skip_err() won't
do anything for the CMDQ_ERR_CERROR_ATC_INV_IDX.
When a device wasn't responsive to an ATC invalidation request, this often
results in constant CMDQ errors:
unexpected global error reported (0x00000001), this could be serious
CMDQ error (cons 0x0302bb84): ATC invalidate timeout
unexpected global error reported (0x00000001), this could be serious
CMDQ error (cons 0x0302bb88): ATC invalidate timeout
unexpected global error reported (0x00000001), this could be serious
CMDQ error (cons 0x0302bb8c): ATC invalidate timeout
...
An ATC invalidation timeout indicates that the device failed to respond to
a protocol-critical coherency request, which means that device's internal
ATS state is desynchronized from the SMMU.
Furthermore, ignoring the timeout leaves the system in an unsafe state, as
the device cache may retain stale ATC entries for memory pages that the OS
has already reclaimed and reassigned. This might lead to data corruption.
Isolate the device that is confirmed to be unresponsive by a surgical STE
update to unset its EATS bit so as to reject any further ATS transaction,
which could corrupt the memory.
Also, set the master->ats_broken flag that is revertible after the device
completes a reset. This flag avoids further ATS requests and invalidations
from happening.
Finally, report this broken device to the IOMMU core to isolate the device
in the core level too.
For batched ATC_INV commands, SMMU hardware only reports a timeout at the
CMD_SYNC, which could follow the batch issued for multiple devices. So, it
isn't straightforward to identify which command in a batch resulted in the
timeout. Fortunately, the invs array has a sorted list of ATC entries. So,
the issued batch must be sorted as well. This makes it possible to retry
the ATC_INV command for each unique Stream ID in the batch to identify the
unresponsive master.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 100 +++++++++++++++++++-
1 file changed, 97 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 5dead82cf1186..7dbd9c5834314 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -107,6 +107,8 @@ static const char * const event_class_str[] = {
[3] = "Reserved",
};
+static struct arm_smmu_ste *
+arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid);
static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master);
static void parse_driver_options(struct arm_smmu_device *smmu)
@@ -2516,10 +2518,49 @@ arm_smmu_atc_inv_to_cmd(int ssid, unsigned long iova, size_t size,
cmd->atc.size = log2_span;
}
+static void arm_smmu_disable_eats_for_sid(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmdq *cmdq, u32 sid)
+{
+ struct arm_smmu_cmdq_ent ent = {
+ .opcode = CMDQ_OP_CFGI_STE,
+ .cfgi = {
+ .sid = sid,
+ .leaf = true,
+ },
+ };
+ struct arm_smmu_ste *step;
+ u64 cmd[CMDQ_ENT_DWORDS];
+ __le64 old, new;
+
+ step = arm_smmu_get_step_for_sid(smmu, sid);
+
+ old = READ_ONCE(step->data[1]);
+ do {
+ new = old & cpu_to_le64(~STRTAB_STE_1_EATS);
+ } while (!try_cmpxchg64(&step->data[1], &old, new));
+
+ arm_smmu_cmdq_build_cmd(cmd, &ent);
+ if (arm_smmu_cmdq_issue_cmdlist(smmu, cmdq, cmd, 1, true))
+ dev_err_ratelimited(smmu->dev,
+ "failed to disable ATS for sid %#x\n", sid);
+}
+
+static void arm_smmu_master_disable_ats(struct arm_smmu_master *master,
+ struct arm_smmu_cmdq *cmdq)
+{
+ int i;
+
+ for (i = 0; i < master->num_streams; i++)
+ arm_smmu_disable_eats_for_sid(master->smmu, cmdq,
+ master->streams[i].id);
+ WRITE_ONCE(master->ats_broken, true);
+ iommu_report_device_broken(master->dev);
+}
+
static int arm_smmu_atc_inv_master(struct arm_smmu_master *master,
ioasid_t ssid)
{
- int i;
+ int i, ret;
struct arm_smmu_cmdq_ent cmd;
struct arm_smmu_cmdq_batch cmds;
@@ -2535,7 +2576,10 @@ static int arm_smmu_atc_inv_master(struct arm_smmu_master *master,
arm_smmu_cmdq_batch_add(master->smmu, &cmds, &cmd);
}
- return arm_smmu_cmdq_batch_submit(master->smmu, &cmds);
+ ret = arm_smmu_cmdq_batch_submit(master->smmu, &cmds);
+ if (ret == -EIO)
+ arm_smmu_master_disable_ats(master, cmds.cmdq);
+ return ret;
}
/* IO_PGTABLE API */
@@ -2682,6 +2726,55 @@ static inline bool arm_smmu_invs_end_batch(struct arm_smmu_inv *cur,
return false;
}
+static void arm_smmu_invs_disable_ats(struct arm_smmu_invs *invs,
+ struct arm_smmu_cmdq *cmdq,
+ struct arm_smmu_device *smmu, u32 sid)
+{
+ struct arm_smmu_inv *cur;
+ size_t i;
+
+ arm_smmu_invs_for_each_entry(invs, i, cur) {
+ if (cur->master->smmu == smmu && arm_smmu_inv_is_ats(cur) &&
+ cur->id == sid) {
+ arm_smmu_master_disable_ats(cur->master, cmdq);
+ break;
+ }
+ }
+}
+
+static void arm_smmu_cmdq_batch_retry(struct arm_smmu_device *smmu,
+ struct arm_smmu_invs *invs,
+ struct arm_smmu_cmdq_batch *cmds)
+{
+ u64 atc[CMDQ_ENT_DWORDS] = {0};
+ int i;
+
+ /* Only a timed out ATC_INV command needs a retry */
+ if (!invs->has_ats)
+ return;
+
+ for (i = 0; i < cmds->num * CMDQ_ENT_DWORDS; i += CMDQ_ENT_DWORDS) {
+ struct arm_smmu_cmdq *cmdq = cmds->cmdq;
+ u32 sid;
+ int ret;
+
+ /* Only need to retry ATC invalidations */
+ if (FIELD_GET(CMDQ_0_OP, cmds->cmds[i]) != CMDQ_OP_ATC_INV)
+ continue;
+
+ /* Only need to retry with one ATC_INV per Stream ID (device) */
+ sid = FIELD_GET(CMDQ_ATC_0_SID, cmds->cmds[i]);
+ if (atc[0] && sid == FIELD_GET(CMDQ_ATC_0_SID, atc[0]))
+ continue;
+
+ atc[0] = cmds->cmds[i];
+ atc[1] = cmds->cmds[i + 1];
+ ret = arm_smmu_cmdq_issue_cmdlist(smmu, cmdq, atc, 1, true);
+ if (ret == -EIO)
+ arm_smmu_invs_disable_ats(invs, cmdq, smmu, sid);
+ }
+}
+
static void __arm_smmu_domain_inv_range(struct arm_smmu_invs *invs,
unsigned long iova, size_t size,
unsigned int granule, bool leaf)
@@ -2760,7 +2853,8 @@ static void __arm_smmu_domain_inv_range(struct arm_smmu_invs *invs,
if (cmds.num &&
(next == end || arm_smmu_invs_end_batch(cur, next))) {
- arm_smmu_cmdq_batch_submit(smmu, &cmds);
+ if (arm_smmu_cmdq_batch_submit(smmu, &cmds) == -EIO)
+ arm_smmu_cmdq_batch_retry(smmu, invs, &cmds);
cmds.num = 0;
}
cur = next;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/4] KVM: arm64: sefltests: Add helpers for guest hypervisors
From: Itaru Kitayama @ 2026-04-16 23:39 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, kvm, linux-kselftest, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Shuah Khan
In-Reply-To: <2grav6nkabbab3e4gm4vtca63kqrpaegq4xqlhdhwc4l32v65i@x5ksiimtk4er>
On Thu, Apr 16, 2026 at 11:15:57PM +0100, Wei-Lin Chang wrote:
> On Wed, Apr 15, 2026 at 07:14:46AM +0900, Itaru Kitayama wrote:
> > On Sun, Apr 12, 2026 at 03:22:14PM +0100, Wei-Lin Chang wrote:
> > > Add helpers so that guest hypervisors can run nested guests. SP_EL1
> > > save/restore is added to allow nested guests to use a stack.
> > >
> > > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > > ---
> > > .../selftests/kvm/include/arm64/nested.h | 17 +++++++
> > > tools/testing/selftests/kvm/lib/arm64/entry.S | 5 ++
> > > .../testing/selftests/kvm/lib/arm64/nested.c | 46 +++++++++++++++++++
> > > 3 files changed, 68 insertions(+)
> > >
> > > diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
> > > index 86d931facacb..7928ef89494a 100644
> > > --- a/tools/testing/selftests/kvm/include/arm64/nested.h
> > > +++ b/tools/testing/selftests/kvm/include/arm64/nested.h
> > > @@ -21,8 +21,17 @@
> > >
> > > extern char hyp_vectors[];
> > >
> > > +enum vcpu_sysreg {
> > > + __INVALID_SYSREG__, /* 0 is reserved as an invalid value */
> > > +
> > > + SP_EL1,
> > > +
> > > + NR_SYS_REGS
> > > +};
> > > +
> > > struct cpu_context {
> > > struct user_pt_regs regs; /* sp = sp_el0 */
> > > + u64 sys_regs[NR_SYS_REGS];
> > > };
> > >
> > > struct vcpu {
> > > @@ -37,9 +46,17 @@ struct hyp_data {
> > > struct cpu_context hyp_context;
> > > };
> >
> > I am not sure of these structs you introduced only for nested guest feature
> > testing, as the KVM arm64 code they are quite complex and involved,
> > extracring part of those and add members as hello_nested or simliar
> > tests evolve, then add test cases to me seems fragile.
> > But if you have strong reason to add these would you mind explaining a bit?
>
> Sorry, I don't quite get all of your points. I understand your argument
> being evolving these structs as time goes is fragile. For this didn't
> KVM itself evolve like this?
>
> As for having these structs, how can we make L1 a small hypervisor
> without them?
You're correct and I was wrong. We will just have to change the structs for
nested virtualization selftests as we add more test cases.
Itaru.
>
> Thanks,
> Wei-Lin Chang
>
> >
> > Thanks,
> > Itaru.
> >
> > >
> > > +void prepare_hyp(void);
> > > +void init_vcpu(struct vcpu *vcpu, vm_paddr_t l2_pc, vm_paddr_t l2_stack_top);
> > > +int run_l2(struct vcpu *vcpu, struct hyp_data *hyp_data);
> > > +
> > > +void do_hvc(void);
> > > u64 __guest_enter(struct vcpu *vcpu, struct cpu_context *hyp_context);
> > > void __hyp_exception(u64 type);
> > >
> > > +void __sysreg_save_el1_state(struct cpu_context *ctxt);
> > > +void __sysreg_restore_el1_state(struct cpu_context *ctxt);
> > > +
> > > #endif /* !__ASSEMBLER__ */
> > >
> > > #endif /* SELFTEST_KVM_NESTED_H */
> > > diff --git a/tools/testing/selftests/kvm/lib/arm64/entry.S b/tools/testing/selftests/kvm/lib/arm64/entry.S
> > > index 33bedf5e7fb2..df3af3463c6c 100644
> > > --- a/tools/testing/selftests/kvm/lib/arm64/entry.S
> > > +++ b/tools/testing/selftests/kvm/lib/arm64/entry.S
> > > @@ -3,6 +3,11 @@
> > > * adapted from arch/arm64/kvm/hyp/entry.S
> > > */
> > >
> > > + .globl do_hvc
> > > + do_hvc:
> > > + hvc #0
> > > + ret
> > > +
> > > /*
> > > * Manually define these for now
> > > */
> > > diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
> > > index 06ddaab2436f..b30d20b101c4 100644
> > > --- a/tools/testing/selftests/kvm/lib/arm64/nested.c
> > > +++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
> > > @@ -4,7 +4,53 @@
> > > */
> > >
> > > #include "nested.h"
> > > +#include "processor.h"
> > > #include "test_util.h"
> > > +#include <asm/sysreg.h>
> > > +
> > > +void prepare_hyp(void)
> > > +{
> > > + write_sysreg(HCR_EL2_E2H | HCR_EL2_RW, hcr_el2);
> > > + write_sysreg(hyp_vectors, vbar_el2);
> > > + isb();
> > > +}
> > > +
> > > +void init_vcpu(struct vcpu *vcpu, vm_paddr_t l2_pc, vm_paddr_t l2_stack_top)
> > > +{
> > > + memset(vcpu, 0, sizeof(*vcpu));
> > > + vcpu->context.regs.pc = l2_pc;
> > > + vcpu->context.regs.pstate = PSR_MODE_EL1h | PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT;
> > > + vcpu->context.sys_regs[SP_EL1] = l2_stack_top;
> > > +}
> > > +
> > > +void __sysreg_save_el1_state(struct cpu_context *ctxt)
> > > +{
> > > + ctxt->sys_regs[SP_EL1] = read_sysreg(sp_el1);
> > > +}
> > > +
> > > +void __sysreg_restore_el1_state(struct cpu_context *ctxt)
> > > +{
> > > + write_sysreg(ctxt->sys_regs[SP_EL1], sp_el1);
> > > +}
> > > +
> > > +int run_l2(struct vcpu *vcpu, struct hyp_data *hyp_data)
> > > +{
> > > + u64 ret;
> > > +
> > > + __sysreg_restore_el1_state(&vcpu->context);
> > > +
> > > + write_sysreg(vcpu->context.regs.pstate, spsr_el2);
> > > + write_sysreg(vcpu->context.regs.pc, elr_el2);
> > > +
> > > + ret = __guest_enter(vcpu, &hyp_data->hyp_context);
> > > +
> > > + vcpu->context.regs.pc = read_sysreg(elr_el2);
> > > + vcpu->context.regs.pstate = read_sysreg(spsr_el2);
> > > +
> > > + __sysreg_save_el1_state(&vcpu->context);
> > > +
> > > + return ret;
> > > +}
> > >
> > > void __hyp_exception(u64 type)
> > > {
> > > --
> > > 2.43.0
> > >
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Yang Shi @ 2026-04-16 23:41 UTC (permalink / raw)
To: Kevin Brodsky, Catalin Marinas
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Suzuki K Poulose, Jinjiang Tu, linux-arm-kernel, linux-kernel,
stable, Kalyazin, Nikita
In-Reply-To: <315131b7-237b-4705-ba84-e03a484128da@arm.com>
On 4/13/26 7:57 AM, Kevin Brodsky wrote:
> On 10/04/2026 01:08, Yang Shi wrote:
>> On 4/9/26 11:33 AM, Catalin Marinas wrote:
>>> On Thu, Apr 09, 2026 at 09:48:58AM -0700, Yang Shi wrote:
>>>> On 4/9/26 8:20 AM, Catalin Marinas wrote:
>>>>> On Thu, Apr 09, 2026 at 11:53:41AM +0200, Kevin Brodsky wrote:
>>>>>> What would make more sense to me is to enable the use of
>>>>>> BBML2-noabort
>>>>>> unconditionally if !force_pte_mapping(). We can then have
>>>>>> can_set_direct_map() return true if we have BBML2-noabort, and we no
>>>>>> longer need to check it in map_mem().
>>>>> Indeed.
>>>> I'm trying to wrap up my head for this discussion. IIUC, if none of the
>>>> features is enabled, it means we don't need do anything because the
>>>> direct
>>>> map is not changed. For example, if vmalloc doesn't change direct map
>>>> permission when rodata != full, there is no need to call
>>>> set_direct_map_*_noflush(). So unconditionally checking
>>>> BBML2_NOABORT will
>>>> change the behavior unnecessarily. Did I miss something?
>>>>
>>>> I think the only exception is secretmem if I don't miss something.
>>>> Currently, secretmem is actually not supported if none of the
>>>> features is
>>>> enabled. But BBML2_NOABORT allows to lift the restriction.
>>> Yes, it's secretmem only AFAICT. I think execmem will only change the
>>> linear map if rodata_full anyway.
>> Yes, execmem calls set_memory_rox(), which won't change linear map
>> permission if rodata_full is not enabled.
> That is a good point, AFAICT set_direct_map_*_noflush() are only used by
> execmem and secretmem. excmem only modifies the direct map if
> rodata=full, so the proposed change would only be useful for secretmem.
>
> The current situation with execmem is pretty strange: if rodata!=full,
> but another feature is enabled (say kfence), then set_memory_rox() won't
> touch the direct map but we will still use set_direct_map_*_noflush() to
> reset it (directly or via VM_FLUSH_RESET_PERMS). Checking BBML2-noabort
> in can_set_direct_map() would make these unnecessary calls more likely,
> but it doesn't fundamentally change the situation.
>
> It's also worth considering the series unmapping parts of the direct map
> for guest_memfd [1], since it gates the use of
> set_direct_map_*_noflush() on can_set_direct_map().
>
> I think it makes complete sense to enable secretmem and the guest_memfd
> use-case if BBML2-noabort is available, regardless of the other
> features. The question is: are we worried about the overhead of
Yes, agreed.
> needlessly calling set_direct_map_*_noflush() for execmem mappings? If
> so, it seems that the right solution is to introduce a new API to check
> whether set_memory_ro() and friends actually modify the direct map or not.
I don't have data regarding the overhead. The set_direct_map_*_noflush()
does walk the page table and they will be called for each page for the
area. It sounds not cheap anyway. In addition, it may split direct map
into smaller granules unnecessarily, it may result in unexpected direct
map fragmentation when rodata != full.
So it seems like introducing a new API is worth it.
Thanks,
Yang
>
> - Kevin
>
> [1] https://lore.kernel.org/lkml/20260317141031.514-1-kalyazin@amazon.com/
^ permalink raw reply
* Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id
From: Jie Gan @ 2026-04-17 1:01 UTC (permalink / raw)
To: Leo Yan, Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin
In-Reply-To: <20260416165541.GN356832@e132581.arm.com>
On 4/17/2026 12:55 AM, Leo Yan wrote:
> On Wed, Apr 15, 2026 at 05:55:22PM +0100, Yeoreum Yun wrote:
>> If etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(),
>> the trace ID may be leaked because it is not released.
>>
>> To address this, call etm4_release_trace_id() when etm4_enable_sysfs()
>> fails in cscfg_csdev_enable_active_config().
>>
>> Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> index f55338a4989d..b199aebbdb60 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> @@ -920,8 +920,10 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa
>> cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset);
>> if (cfg_hash) {
>> ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset);
>> - if (ret)
>> + if (ret) {
>> + etm4_release_trace_id(drvdata);
>> return ret;
>> + }
>
> LGTM:
>
> Reviewed-by: Leo Yan <leo.yan@arm.com>
>
> Just recording a bit thoughts. As Suzuki mentioned, it would be better
> to allocate trace IDs within a session. We might consider maintaining
> the trace ID map in the sink driver data, since the sink driver is
> unique within a session so it is a central place to allocate trace ID.
>
> We should use paired way for allocation and release. For example:
>
> coresight_enable_sysfs()
> {
> ...
> coresight_path_assign_trace_id(path);
>
> failed:
> coresight_path_unassign_trace_id(path);
> }
>
> coresight_disable_sysfs()
> {
> coresight_path_unassign_trace_id(path);
> }
>
> But this requires broader refactoring. E.g., the STM driver currently
> allocates system trace IDs statically during probe, we might need to
> consolidate for all modules to use dynamic allocation.
Agree. That's making sense. Currently, the trace ID of some devices is
allocated during probe, and never to be released. It's kind of waste of
our trace ID resource if the device never to be enabled. But we still
need support static trace ID allocation in parallel for the dummy
sources and we should not break this logic in future refactor.
Thanks,
Jie
>
> Thanks,
> Leo
^ permalink raw reply
* Re: arm64: Supporting DYNAMIC_FTRACE_WITH_CALL_OPS with CLANG_CFI
From: Clayton Craft @ 2026-04-17 1:10 UTC (permalink / raw)
To: Puranjay Mohan, catalin.marinas, ast, daniel, mark.rutland,
broonie, linux-arm-kernel, linux-kernel, bpf
Cc: craftyguy
In-Reply-To: <mb61pedcvxdhw.fsf@gmail.com>
On Thu Feb 29, 2024 at 11:43 AM PST, Puranjay Mohan wrote:
> puranjay12@gmail.com writes:
> I hacked some patches and tried the above approach:
>
> Here are the patches(RFC) that I created:
>
> LLVM Patch:
Hi Puranjay,
Did this LLVM patch ever make it upstream? I'd like to use CFI together
with BPF LSM on arm64 and wondering what the current state of this
effort is.
Thanks,
Clayton
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
From: patchwork-bot+netdevbpf @ 2026-04-17 2:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414-airoha-wait-for-npu-config-offload-setup-v2-1-5a9bf6d43aee@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 14 Apr 2026 16:08:52 +0200 you wrote:
> In order to properly enable flowtable hw offloading, poll
> REG_PPE_FLOW_CFG register in airoha_ppe_offload_setup routine and
> wait for NPU PPE configuration triggered by ppe_init callback to complete
> before running airoha_ppe_hw_init().
>
> Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net,v2] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
https://git.kernel.org/netdev/net/c/f3206328bb52
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] dt-bindings: Remove the redundant 'type: boolean'
From: phucduc.bui @ 2026-04-17 2:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt
Cc: nick, dmitry.torokhov, nicolas.ferre, alexandre.belloni,
claudiu.beznea, lee, heiko, gregkh, linusw, zyw, zhangqing,
gene_chen, linux-input, devicetree, linux-arm-kernel, linux-usb,
bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
The 'wakeup-source' property already has its type defined in the core
schema. Remove the redundant 'type: boolean' from the binding file to
clean up the binding files.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 3 +--
Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml | 3 +--
Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index 9bf07acea599..26ea78df27c4 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -88,8 +88,7 @@ properties:
- 2 # ATMEL_MXT_WAKEUP_GPIO
default: 0
- wakeup-source:
- type: boolean
+ wakeup-source: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
index 0676890f101e..a58d9455a1a5 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
@@ -44,8 +44,7 @@ properties:
description:
Telling whether or not this PMIC is controlling the system power.
- wakeup-source:
- type: boolean
+ wakeup-source: true
vcc1-supply:
description:
diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
index ae611f7e57ca..ec0d83220527 100644
--- a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
@@ -33,8 +33,7 @@ properties:
vbus-supply:
description: VBUS power supply
- wakeup-source:
- type: boolean
+ wakeup-source: true
connector:
type: object
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Billy Tsai @ 2026-04-17 2:20 UTC (permalink / raw)
To: Conor Dooley
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20260416-brutishly-saga-ba7168a4cd14@spud>
> > + properties:
> > + function:
> > + enum:
> > + - EMMC
> > + - JTAGDDR
> > + - JTAGM0
> > + - JTAGPCIEA
> > + - JTAGPCIEB
> > + - JTAGPSP
> > + - JTAGSSP
> > + - JTAGTSP
> > + - JTAGUSB3A
> > + - JTAGUSB3B
> > + - PCIERC0PERST
> > + - PCIERC1PERST
> > + - TSPRSTN
> > + - UFSCLKI
> > + - USB2AD0
> > + - USB2AD1
> > + - USB2AH
> > + - USB2AHP
> > + - USB2AHPD0
> > + - USB2AXH
> > + - USB2AXH2B
> > + - USB2AXHD1
> > + - USB2AXHP
> > + - USB2AXHP2B
> > + - USB2AXHPD1
> > + - USB2BD0
> > + - USB2BD1
> > + - USB2BH
> > + - USB2BHP
> > + - USB2BHPD0
> > + - USB2BXH
> > + - USB2BXH2A
> > + - USB2BXHD1
> > + - USB2BXHP
> > + - USB2BXHP2A
> > + - USB2BXHPD1
> > + - USB3AXH
> > + - USB3AXH2B
> > + - USB3AXHD
> > + - USB3AXHP
> > + - USB3AXHP2B
> > + - USB3AXHPD
> > + - USB3BXH
> > + - USB3BXH2A
> > + - USB3BXHD
> > + - USB3BXHP
> > + - USB3BXHP2A
> > + - USB3BXHPD
> > + - VB
> > + - VGADDC
> > +
> > + groups:
> > + enum:
> > + - EMMCCDN
> > + - EMMCG1
> > + - EMMCG4
> > + - EMMCG8
> > + - EMMCWPN
> > + - JTAG0
> > + - PCIERC0PERST
> > + - PCIERC1PERST
> > + - TSPRSTN
> > + - UFSCLKI
> > + - USB2A
> > + - USB2AAP
> > + - USB2ABP
> > + - USB2ADAP
> > + - USB2AH
> > + - USB2AHAP
> > + - USB2B
> > + - USB2BAP
> > + - USB2BBP
> > + - USB2BDBP
> > + - USB2BH
> > + - USB2BHBP
> > + - USB3A
> > + - USB3AAP
> > + - USB3ABP
> > + - USB3B
> > + - USB3BAP
> > + - USB3BBP
> > + - VB0
> > + - VB1
> > + - VGADDC
> > + pins:
> > + enum:
> > + - AB13
> > + - AB14
> > + - AC13
> > + - AC14
> > + - AD13
> > + - AD14
> > + - AE13
> > + - AE14
> > + - AE15
> > + - AF13
> > + - AF14
> > + - AF15
> Why do you have groups and pins?
> Is it valid in your device to have groups and pins in the same node?
The intent is to support both group-based mux selection and
configuration, as well as per-pin configuration.
In our hardware:
- `function` + `groups` are used for pinmux selection.
- `pins` is used for per-pin configuration (e.g. drive strength,
bias settings).
- `groups` may also be used for group-level configuration.
As a result, both `groups` and `pins` may appear in the same node,
but they serve different purposes and do not conflict:
- `groups` selects the mux function and may apply configuration to
the entire group.
- `pins` allows overriding or specifying configuration for individual
pins.
In most cases, only one of them is needed, but both are allowed when
both group-level and per-pin configuration are required.
Thanks
Billy Tsai
^ permalink raw reply
* Re: [PATCH v2 net 0/2] net: enetc: fix command BD ring issues
From: patchwork-bot+netdevbpf @ 2026-04-17 2:40 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, chleroy, netdev, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260415060833.2303846-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 14:08:31 +0800 you wrote:
> Currently, the implementation of command BD ring has two issues, one is
> that the driver may obtain wrong consumer index of the ring, because the
> driver does not mask out the SBE bit of the CIR value, so a wrong index
> will be obtained when a SBE error ouccrs. The other one is that the DMA
> buffer may be used after free. If netc_xmit_ntmp_cmd() times out and
> returns an error, the pending command is not explicitly aborted, while
> ntmp_free_data_mem() unconditionally frees the DMA buffer. If the buffer
> has already been reallocated elsewhere, this may lead to silent memory
> corruption. Because the hardware eventually processes the pending command
> and perform a DMA write of the response to the physical address of the
> freed buffer. So this patch set is to fix these two issues.
>
> [...]
Here is the summary with links:
- [v2,net,1/2] net: enetc: correct the command BD ring consumer index
https://git.kernel.org/netdev/net/c/759a32900b6f
- [v2,net,2/2] net: enetc: fix NTMP DMA use-after-free issue
https://git.kernel.org/netdev/net/c/3cade698881e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-17 3:17 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260416203905.GA29913@bhelgaas>
> On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > Introduce generic helper functions to parse Root Port device tree
> > nodes and extract common properties like reset GPIOs. This allows
> > multiple PCI host controller drivers to share the same parsing logic.
> >
> > Define struct pci_host_port to hold common Root Port properties
> > (currently only reset GPIO descriptor) and add
> > pci_host_common_parse_ports() to parse Root Port nodes from device
> tree.
>
> Are the Root Port and the RC the only possible places for 'reset' GPIO
> descriptions in DT? I think PERST# routing is outside the PCIe spec, so it
> seems like a system could provide a PERST# GPIO routed to any Switch
> Upstream Port or Endpoint (I assume a PERST# connected to a switch would
> apply to both the upstream port and the downstream ports).
Hi Bjorn,
Thanks for the feedback. You're right that PERST# routing could theoretically be
connected to any device in the hierarchy. However, for this patch series, I've focused
on the most common use case in practice: use Root Port level PERST# instead of the
legacy Root Complex level PERST#.
Root Port level PERST# - This is the primary target, where each Root Port has individual
control over devices connected to it.
RC level PERST# - Legacy binding support, where a single GPIO controls all ports.
We can extend this framework later if real hardware emerges that needs Switch or
EP-level PERST# control. I can add a comment documenting this limitation if needed.
BTW, Mani and Rob had some great discussions in dt-schema about PERST# and WAKE#
sideband signals settings.
You can check here:
https://github.com/devicetree-org/dt-schema/issues/168
https://github.com/devicetree-org/dt-schema/pull/126
https://github.com/devicetree-org/dt-schema/pull/170
Best Regards
Sherry
^ permalink raw reply
* [PATCH] gpio: drop bitmap_complement() where feasible
From: Yury Norov @ 2026-04-17 3:34 UTC (permalink / raw)
To: Linus Walleij, Andy Shevchenko, Bartosz Golaszewski,
Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, linux-gpio,
linux-kernel, linux-arm-kernel
Cc: Yury Norov
The gpio drivers reproduce the following pattern:
bitmap_complement(tmp, data1, nbits);
bitmap_and(dst, data2, tmp, nbits);
This can be done in a single pass:
bitmap_andnot(dst, data2, data1t, nbits);
Signed-off-by: Yury Norov <ynorov@nvidia.com>
---
drivers/gpio/gpio-pca953x.c | 7 ++-----
drivers/gpio/gpio-xilinx.c | 6 ++----
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 52e96cc5f67b..1fef733fe1f0 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -877,11 +877,9 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
bitmap_or(irq_mask, chip->irq_trig_fall, chip->irq_trig_raise, gc->ngpio);
bitmap_or(irq_mask, irq_mask, chip->irq_trig_level_high, gc->ngpio);
bitmap_or(irq_mask, irq_mask, chip->irq_trig_level_low, gc->ngpio);
- bitmap_complement(reg_direction, reg_direction, gc->ngpio);
- bitmap_and(irq_mask, irq_mask, reg_direction, gc->ngpio);
/* Look for any newly setup interrupt */
- for_each_set_bit(level, irq_mask, gc->ngpio)
+ for_each_andnot_bit(level, irq_mask, reg_direction, gc->ngpio)
pca953x_gpio_direction_input(&chip->gpio_chip, level);
mutex_unlock(&chip->irq_lock);
@@ -1005,8 +1003,7 @@ static bool pca953x_irq_pending(struct pca953x_chip *chip, unsigned long *pendin
bitmap_and(cur_stat, cur_stat, chip->irq_mask, gc->ngpio);
bitmap_or(pending, pending, cur_stat, gc->ngpio);
- bitmap_complement(cur_stat, new_stat, gc->ngpio);
- bitmap_and(cur_stat, cur_stat, reg_direction, gc->ngpio);
+ bitmap_andnot(cur_stat, reg_direction, new_stat, gc->ngpio);
bitmap_and(old_stat, cur_stat, chip->irq_trig_level_low, gc->ngpio);
bitmap_and(old_stat, old_stat, chip->irq_mask, gc->ngpio);
bitmap_or(pending, pending, old_stat, gc->ngpio);
diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index be4b4d730547..532205175827 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -495,13 +495,11 @@ static void xgpio_irqhandler(struct irq_desc *desc)
xgpio_read_ch_all(chip, XGPIO_DATA_OFFSET, hw);
- bitmap_complement(rising, chip->last_irq_read, 64);
- bitmap_and(rising, rising, hw, 64);
+ bitmap_andnot(rising, hw, chip->last_irq_read, 64);
bitmap_and(rising, rising, chip->enable, 64);
bitmap_and(rising, rising, chip->rising_edge, 64);
- bitmap_complement(falling, hw, 64);
- bitmap_and(falling, falling, chip->last_irq_read, 64);
+ bitmap_andnot(falling, chip->last_irq_read, hw, 64);
bitmap_and(falling, falling, chip->enable, 64);
bitmap_and(falling, falling, chip->falling_edge, 64);
--
2.51.0
^ permalink raw reply related
* [PATCH net] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-04-17 3:55 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Christian Marangi, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Frank Wunderlich, John Crispin
The .get_stats64 callback runs in atomic context, but on
MDIO-connected switches every register read acquires the MDIO bus
mutex, which can sleep:
[ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
[ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
[ 12.663377] preempt_count: 0, expected: 0
[ 12.667410] RCU nest depth: 1, expected: 0
[ 12.671511] INFO: lockdep is turned off.
[ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
[ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
[ 12.675459] Call trace:
[ 12.675462] show_stack+0x14/0x1c (C)
[ 12.675477] dump_stack_lvl+0x68/0x8c
[ 12.675487] dump_stack+0x14/0x1c
[ 12.675495] __might_resched+0x14c/0x220
[ 12.675504] __might_sleep+0x44/0x80
[ 12.675511] __mutex_lock+0x50/0xb10
[ 12.675523] mutex_lock_nested+0x20/0x30
[ 12.675532] mt7530_get_stats64+0x40/0x2ac
[ 12.675542] dsa_user_get_stats64+0x2c/0x40
[ 12.675553] dev_get_stats+0x44/0x1e0
[ 12.675564] dev_seq_printf_stats+0x24/0xe0
[ 12.675575] dev_seq_show+0x14/0x3c
[ 12.675583] seq_read_iter+0x37c/0x480
[ 12.675595] seq_read+0xd0/0xec
[ 12.675605] proc_reg_read+0x94/0xe4
[ 12.675615] vfs_read+0x98/0x29c
[ 12.675625] ksys_read+0x54/0xdc
[ 12.675633] __arm64_sys_read+0x18/0x20
[ 12.675642] invoke_syscall.constprop.0+0x54/0xec
[ 12.675653] do_el0_svc+0x3c/0xb4
[ 12.675662] el0_svc+0x38/0x200
[ 12.675670] el0t_64_sync_handler+0x98/0xdc
[ 12.675679] el0t_64_sync+0x158/0x15c
For MDIO-connected switches, poll MIB counters asynchronously using a
delayed workqueue every second and let .get_stats64 return the cached
values under a per-port spinlock. A mod_delayed_work() call on each
read triggers an immediate refresh so counters stay responsive when
queried more frequently.
MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
because their regmap does not sleep, so they continue to read MIB
counters directly in .get_stats64.
Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
This bug highlights a bigger problem and the actual cause:
Locking in the mt7530 driver deserves a cleanup, and refactoring
towards cleanly and directly using the regmap API.
I've prepared this already and am going to submit a series doing
most of that using Coccinelle semantic patches once net-next opens
again.
drivers/net/dsa/mt7530.c | 54 +++++++++++++++++++++++++++++++++++++---
drivers/net/dsa/mt7530.h | 6 +++++
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index b9423389c2ef0..786d3a8492bcb 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -25,6 +25,8 @@
#include "mt7530.h"
+#define MT7530_STATS_POLL_INTERVAL (1 * HZ)
+
static struct mt753x_pcs *pcs_to_mt753x_pcs(struct phylink_pcs *pcs)
{
return container_of(pcs, struct mt753x_pcs, pcs);
@@ -906,10 +908,9 @@ static void mt7530_get_rmon_stats(struct dsa_switch *ds, int port,
*ranges = mt7530_rmon_ranges;
}
-static void mt7530_get_stats64(struct dsa_switch *ds, int port,
- struct rtnl_link_stats64 *storage)
+static void mt7530_read_port_stats64(struct mt7530_priv *priv, int port,
+ struct rtnl_link_stats64 *storage)
{
- struct mt7530_priv *priv = ds->priv;
uint64_t data;
/* MIB counter doesn't provide a FramesTransmittedOK but instead
@@ -951,6 +952,43 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
&storage->rx_crc_errors);
}
+static void mt7530_stats_poll(struct work_struct *work)
+{
+ struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
+ stats_work.work);
+ struct rtnl_link_stats64 stats = {};
+ struct dsa_port *dp;
+ int port;
+
+ dsa_switch_for_each_user_port(dp, priv->ds) {
+ port = dp->index;
+
+ mt7530_read_port_stats64(priv, port, &stats);
+
+ spin_lock(&priv->stats_lock);
+ priv->ports[port].stats = stats;
+ spin_unlock(&priv->stats_lock);
+ }
+
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+}
+
+static void mt7530_get_stats64(struct dsa_switch *ds, int port,
+ struct rtnl_link_stats64 *storage)
+{
+ struct mt7530_priv *priv = ds->priv;
+
+ if (priv->bus) {
+ spin_lock(&priv->stats_lock);
+ *storage = priv->ports[port].stats;
+ spin_unlock(&priv->stats_lock);
+ mod_delayed_work(system_wq, &priv->stats_work, 0);
+ } else {
+ mt7530_read_port_stats64(priv, port, storage);
+ }
+}
+
static void mt7530_get_eth_ctrl_stats(struct dsa_switch *ds, int port,
struct ethtool_eth_ctrl_stats *ctrl_stats)
{
@@ -3137,6 +3175,13 @@ mt753x_setup(struct dsa_switch *ds)
if (ret && priv->irq_domain)
mt7530_free_mdio_irq(priv);
+ if (!ret && priv->bus) {
+ spin_lock_init(&priv->stats_lock);
+ INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+ }
+
return ret;
}
@@ -3404,6 +3449,9 @@ EXPORT_SYMBOL_GPL(mt7530_probe_common);
void
mt7530_remove_common(struct mt7530_priv *priv)
{
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+
if (priv->irq_domain)
mt7530_free_mdio_irq(priv);
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 3e0090bed298d..44c1dc75baea8 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -796,6 +796,7 @@ struct mt7530_fdb {
* @pvid: The VLAN specified is to be considered a PVID at ingress. Any
* untagged frames will be assigned to the related VLAN.
* @sgmii_pcs: Pointer to PCS instance for SerDes ports
+ * @stats: Cached port statistics for MDIO-connected switches
*/
struct mt7530_port {
bool enable;
@@ -803,6 +804,7 @@ struct mt7530_port {
u32 pm;
u16 pvid;
struct phylink_pcs *sgmii_pcs;
+ struct rtnl_link_stats64 stats;
};
/* Port 5 mode definitions of the MT7530 switch */
@@ -875,6 +877,8 @@ struct mt753x_info {
* @create_sgmii: Pointer to function creating SGMII PCS instance(s)
* @active_cpu_ports: Holding the active CPU ports
* @mdiodev: The pointer to the MDIO device structure
+ * @stats_lock: Protects cached per-port stats from concurrent access
+ * @stats_work: Delayed work for polling MIB counters on MDIO switches
*/
struct mt7530_priv {
struct device *dev;
@@ -900,6 +904,8 @@ struct mt7530_priv {
int (*create_sgmii)(struct mt7530_priv *priv);
u8 active_cpu_ports;
struct mdio_device *mdiodev;
+ spinlock_t stats_lock; /* protects cached stats counters */
+ struct delayed_work stats_work;
};
struct mt7530_hw_vlan_entry {
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL 1/4] soc: dt changes for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <b3203b1d-4c1d-49b8-924e-c17cf6be7ec0@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:22:48 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-dt-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e65f4718a577fcc84d40431f022985898b6dbf2e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL 3/4] soc: defconfig updates for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <704b8a79-4fe5-4815-82aa-026de29dcf1a@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:30:16 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-defconfig-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/231d703058b2e2ee59884c8531e02c60a2a109ab
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: Re: [GIT PULL 2/4] soc: drivers for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <d80b4370-3d20-4d7c-b91f-455797c52b39@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:28:45 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-drivers-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/31b43c079f9aa55754c20404a42bca9a49e01f60
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL 4/4] soc: ARM code changes for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <2af6e914-7d5f-4976-8b18-0a98ad3a427c@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:31:18 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-arm-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8242c709d4ba858c483ef7ef3cc2dc1280f5383c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver
From: Deep Pani @ 2026-04-17 6:02 UTC (permalink / raw)
To: Fred-WY Chen (陳威宇),
andriy.shevchenko@intel.com, Lei Xue (薛磊),
Mandeep S
Cc: Qingliang Li (黎晴亮), sean.wang@kernel.org,
Yaoy Wang (王瑶瑶), AngeloGioacchino Del Regno,
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Cathy Xu (许华婷),
Shunxi Zhang (章顺喜),
Ye Wang (王叶)
In-Reply-To: <9e802950ae47071bb34bb373419dc89c9add9d0b.camel@mediatek.com>
Hi Andy,
Any updates from your side?
Thanks and Regards,
Deep Pani
On Fri, 2026-03-27 at 21:33 +0800, Deep Pani wrote:
> Hi Andy,
>
> You mean gpiochip_add_pin_range(), correct?
>
> IIRC, that adds to gpiochip's range, not the range we are using for
> our
> pinctrl driver.
>
> The range we are utilizing inside our hardware is of the type struct
> pinctrl_gpio_range. There is no callback in gpiochip that handles
> this
> type of range
>
> I also recall that gpiochip_add_data() doesn't initialize the hw but
> rather initializes the gpiochip from the hw data we will provide in
> mtk_build_gpiochip(). Thus we need a function which will help
> initialize the pinctrl_gpio_range inside our pinctrl driver
> structure.
> This is why we make the mtk_pinctrl_gpio_range_init function here.
>
> For the second question, we are keeping it because before ACPI is
> invoked we still need some other pins to be configured, especially if
> different pins have different styles of pull configuration. The
> method
> we use is to define those configurations in the pinctrl-mt8901.c file
> which determines the gpio ranges and maps pinctrl device to acpi, one
> set of gpio ranges per configuration, for different type of pull
> configurations we have different gpio ranges, this callback helps add
> them into the pinctrl subsystem such that other device maintainers
> can
> easily leverage that subsystem to add their resources in their _CRS
> calls using the common interfaces.
>
> Thus we need to keep both the functions.
>
> Thanks and Regards,
> Deep Pani
>
>
>
> On Thu, 2026-03-26 at 12:33 +0000, Fred-WY Chen (陳威宇) wrote:
> > On Wed, 2025-11-26 at 19:06 +0100, Andy Shevchenko wrote:
> > >
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >
> > >
> > > On Tue, Nov 25, 2025 at 10:36:34AM +0800, Lei Xue wrote:
> > > > Kernel GPIO subsystem mapping hardware pin number to a
> > > > different
> > > > range of gpio number. Add gpio-range structure to hold
> > > > the mapped gpio range in pinctrl driver. That enables the
> > > > kernel
> > > > to search a range of mapped gpio range against a pinctrl
> > > > device.
> > >
> > > ...
> > >
> > > > static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
> > > > {
> > > > struct gpio_chip *chip = &hw->chip;
> > >
> > > > if (ret < 0)
> > > > return ret;
> > > >
> > > > + mtk_pinctrl_gpio_range_init(hw, chip);
> > > > +
> > > > return 0;
> > >
> > > We have a callback for that in struct gpio_chip. Any reason not
> > > to
> > > use it?
> > >
> > > > }
> > >
> > > ...
> > >
> > > > + pinctrl_add_gpio_range(hw->pctrl, &hw->range);
> > >
> > > Not sure if this is needed.
> > >
> >
> > Hi Deep,
> >
> > Could you please check this and feedback?
> >
> > Regards,
> > Fred-WY Chen
> >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> > >
> > >
> >
>
^ permalink raw reply
* Re: [PATCH 3/3] pinctrl: mediatek: mt8901: Add pinctrl driver for MT8901
From: Deep Pani @ 2026-04-17 6:04 UTC (permalink / raw)
To: linus.walleij@linaro.org, Fred-WY Chen (陳威宇),
AngeloGioacchino Del Regno, sean.wang@kernel.org,
matthias.bgg@gmail.com, Mandeep S, Lei Xue (薛磊)
Cc: Qingliang Li (黎晴亮),
Ye Wang (王叶), Yaoy Wang (王瑶瑶),
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
Shunxi Zhang (章顺喜),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Cathy Xu (许华婷)
In-Reply-To: <666207716ac5021e81736c30e802ba2febfed081.camel@mediatek.com>
Hi Angelo,
Are there any updates from your side?
Thanks and Regards,
Deep Pani
On Fri, 2026-03-27 at 21:41 +0800, Deep Pani wrote:
> Hi Angelo,
>
> MT8901 doesn't use devicetree for gpio pin configuration. ACPI ASL
> macros are declared in the device's _CRS methods to define exact
> configuration for the gpio pins.
>
> We have and will always make sure ACPI is all good on this platform.
>
> Thanks and Regards,
> Deep Pani
>
> On Thu, 2026-03-26 at 12:36 +0000, Fred-WY Chen (陳威宇) wrote:
> > On Tue, 2025-11-25 at 10:56 +0100, AngeloGioacchino Del Regno
> > wrote:
> > >
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >
> > >
> > > Il 25/11/25 03:36, Lei Xue ha scritto:
> > > > Add mt8901 pinctrl, gpio and eint driver implementation.
> > > >
> > > > Signed-off-by: Lei Xue <lei.xue@mediatek.com>
> > > > ---
> > > > drivers/pinctrl/mediatek/Kconfig | 12 +
> > > > drivers/pinctrl/mediatek/Makefile | 1 +
> > > > drivers/pinctrl/mediatek/mtk-eint.c | 4 +
> > > > drivers/pinctrl/mediatek/mtk-eint.h | 1 +
> > > > drivers/pinctrl/mediatek/pinctrl-mt8901.c | 1460
> > > > +++++++++++
> > > > drivers/pinctrl/mediatek/pinctrl-mtk-mt8901.h | 2130
> > > > +++++++++++++++++
> > > > 6 files changed, 3608 insertions(+)
> > > > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-
> > > > mt8901.h
> > > >
> > > > diff --git a/drivers/pinctrl/mediatek/Kconfig
> > > > b/drivers/pinctrl/mediatek/Kconfig
> > > > index 4819617d9368..4820ae5197a0 100644
> > > > --- a/drivers/pinctrl/mediatek/Kconfig
> > > > +++ b/drivers/pinctrl/mediatek/Kconfig
> > > > @@ -321,6 +321,18 @@ config PINCTRL_MT8516
> > > > default ARM64 && ARCH_MEDIATEK
> > > > select PINCTRL_MTK
> > > >
> > > > +config PINCTRL_MT8901
> > > > + bool "MediaTek MT8901 pin control"
> > > > + depends on ACPI
> > > > + depends on ARM64 || COMPILE_TEST
> > > > + default ARM64 && ARCH_MEDIATEK
> > > > + select PINCTRL_MTK_PARIS
> > > > + help
> > > > + Say yes here to support pin controller and gpio driver
> > > > + on MediaTek MT8901 SoC.
> > > > + In MTK platform, we support virtual gpio and use it to
> > > > + map specific eint which doesn't have real gpio pin.
> > > > +
> > > > # For PMIC
> > > > config PINCTRL_MT6397
> > > > bool "MediaTek MT6397 pin control"
> > > > diff --git a/drivers/pinctrl/mediatek/Makefile
> > > > b/drivers/pinctrl/mediatek/Makefile
> > > > index ae765bd99965..57c69b1e5c2d 100644
> > > > --- a/drivers/pinctrl/mediatek/Makefile
> > > > +++ b/drivers/pinctrl/mediatek/Makefile
> > > > @@ -43,3 +43,4 @@ obj-$(CONFIG_PINCTRL_MT8196)
> > > > +=
> > > > pinctrl-mt8196.o
> > > > obj-$(CONFIG_PINCTRL_MT8365) += pinctrl-
> > > > mt8365.o
> > > > obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-
> > > > mt8516.o
> > > > obj-$(CONFIG_PINCTRL_MT6397) += pinctrl-
> > > > mt6397.o
> > > > +obj-$(CONFIG_PINCTRL_MT8901) += pinctrl-mt8901.o
> > > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
> > > > b/drivers/pinctrl/mediatek/mtk-eint.c
> > > > index c8c5097c11c4..b5a5beebf9cd 100644
> > > > --- a/drivers/pinctrl/mediatek/mtk-eint.c
> > > > +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> > > > @@ -71,6 +71,10 @@ const unsigned int debounce_time_mt6878[] =
> > > > {
> > > > };
> > > > EXPORT_SYMBOL_GPL(debounce_time_mt6878);
> > > >
> > > > +const unsigned int debounce_time_mt8901[] = {
> > > > + 156, 313, 625, 1250, 20000, 40000, 80000, 160000, 320000,
> > > > 640000, 0};
> > > > +EXPORT_SYMBOL_GPL(debounce_time_mt8901);
> > > > +
> > > > static void __iomem *mtk_eint_get_offset(struct mtk_eint
> > > > *eint,
> > > > unsigned int eint_num,
> > > > unsigned int offset)
> > > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> > > > b/drivers/pinctrl/mediatek/mtk-eint.h
> > > > index 3cdd6f6310cd..1b185f660aff 100644
> > > > --- a/drivers/pinctrl/mediatek/mtk-eint.h
> > > > +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> > > > @@ -53,6 +53,7 @@ extern const unsigned int
> > > > debounce_time_mt2701[];
> > > > extern const unsigned int debounce_time_mt6765[];
> > > > extern const unsigned int debounce_time_mt6795[];
> > > > extern const unsigned int debounce_time_mt6878[];
> > > > +extern const unsigned int debounce_time_mt8901[];
> > > >
> > > > struct mtk_eint;
> > > >
> > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > new file mode 100644
> > > > index 000000000000..77dec85fe29b
> > > > --- /dev/null
> > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > @@ -0,0 +1,1460 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (C) 2025 MediaTek Inc.
> > > > + *
> > > > + */
> > > > +
> > > > +#include <linux/acpi.h>
> > > > +#include <linux/module.h>
> > > > +#include "pinctrl-mtk-mt8901.h"
> > > > +#include "pinctrl-paris.h"
> > > > +
> > >
> > > ..snip..
> > >
> > > > +static const char * const mt8901_pinctrl_register_base_name[]
> > > > =
> > > > {
> > > > + "iocfg0", "iocfg_lt2", "iocfg_lt3", "iocfg_rt1",
> > > > "iocfg_rt2",
> > > > "iocfg_rt3",
> > > > + "iocfg_tr", "iocfg_rt0", "iocfg_lt1", "iocfg_lb",
> > > > "iocfg_rb",
> > > > +};
> > > > +
> > > > +static const struct mtk_eint_hw mt8901_eint_hw = {
> > > > + .port_mask = 0xf,
> > > > + .ports = 7,
> > > > + .ap_num = 209,
> > > > + .db_cnt = 32,
> > > > + .db_time = debounce_time_mt8901,
> > > > +};
> > > > +
> > > > +static const struct mtk_pin_soc mt8901_data = {
> > > > + .reg_cal = mt8901_reg_cals,
> > > > + .pins = mtk_pins_mt8901,
> > > > + .npins = ARRAY_SIZE(mtk_pins_mt8901),
> > > > + .ngrps = ARRAY_SIZE(mtk_pins_mt8901),
> > > > + .eint_hw = &mt8901_eint_hw,
> > > > + .eint_pin = eint_pins_mt8901,
> > > > + .nfuncs = 8,
> > > > + .gpio_m = 0,
> > > > + .base_names = mt8901_pinctrl_register_base_name,
> > > > + .nbase_names =
> > > > ARRAY_SIZE(mt8901_pinctrl_register_base_name),
> > > > + .pull_type = mt8901_pull_type,
> > > > + .pin_rsel = mt8901_pin_rsel_val_range,
> > > > + .npin_rsel = ARRAY_SIZE(mt8901_pin_rsel_val_range),
> > > > /*numsel*/
> > > > + .bias_set_combo = mtk_pinconf_bias_set_combo,
> > > > + .bias_get_combo = mtk_pinconf_bias_get_combo,
> > > > + .drive_set = mtk_pinconf_drive_set_rev1,
> > > > + .drive_get = mtk_pinconf_drive_get_rev1,
> > > > + .adv_drive_set = mtk_pinconf_adv_drive_set_raw,
> > > > + .adv_drive_get = mtk_pinconf_adv_drive_get_raw,
> > > > +};
> > > > +
> > > > +static const struct acpi_device_id mt8901_pinctrl_acpi_match[]
> > > > =
> > > > {
> > > > + {"NVDA9221", (kernel_ulong_t)&mt8901_data },
> > > > + { }
> > > > +};
> > > > +MODULE_DEVICE_TABLE(acpi, mt8901_pinctrl_acpi_match);
> > > > +
> > > > +static struct platform_driver mt8901_pinctrl_driver = {
> > > > + .driver = {
> > > > + .name = "mt8901-pinctrl",
> > > > + .acpi_match_table =
> > > > ACPI_PTR(mt8901_pinctrl_acpi_match),
> > >
> > > Please also add support for devicetree - I have a hunch (and I'm
> > > sure
> > > that I am
> > > not the only one) that ACPI may give some issues at the end of
> > > the
> > > day, on ARM64.
> > >
> > > Of course, I'd hope that ACPI is all good on this platform, but
> > > still.... :-)
> > >
> > > static const struct of_device_id mt8901_pinctrl_of_match[] = {
> > > { .compatible = "mediatek,mt8901-pinctrl", .data =
> > > &mt8901_data },
> > > { /* sentinel */ }
> > > };
> > >
> > > .of_match_table = mt8901_pinctrl_of_match,
> > >
> > > > + .pm = pm_sleep_ptr(&mtk_paris_pinctrl_pm_ops)
> > > > + },
> > > > + .probe = mtk_paris_pinctrl_probe,
> > > > +};
> > >
> >
> > Hi Deep,
> >
> > Could you please check and feedback to Angelo?
> >
> > Regards,
> > Fred-WY Chen
> >
> > > Cheers,
> > > Angelo
> > >
> > > > +
> > > > +static int __init mt8901_pinctrl_init(void)
> > > > +{
> > > > + return platform_driver_register(&mt8901_pinctrl_driver);
> > > > +}
> > > > +
> > > > +arch_initcall(mt8901_pinctrl_init);
> > > > +
> > > > +MODULE_LICENSE("GPL");
> > > > +MODULE_DESCRIPTION("MediaTek MT8901 Pinctrl Driver");
> >
>
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support
From: Andy Shevchenko @ 2026-04-17 6:26 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Linus Walleij, Lei Xue, Hanjun Guo, Sudeep Holla, Sean Wang,
Linus Walleij, Matthias Brugger, AngeloGioacchino Del Regno,
linux-kernel, linux-mediatek, linux-gpio, linux-arm-kernel,
yong.mao, qingliang.li, Fred-WY.Chen, ot_cathy.xu,
ot_shunxi.zhang, ot_yaoy.wang, ot_ye.wang, linux-acpi, robh
In-Reply-To: <aSh0EyGm9ZHAc3dN@lpieralisi>
On Thu, Nov 27, 2025 at 04:53:55PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Nov 27, 2025 at 04:29:54PM +0200, Andy Shevchenko wrote:
> > On Thu, Nov 27, 2025 at 11:06:29AM +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Nov 26, 2025 at 08:06:51PM +0200, Andy Shevchenko wrote:
[...]
> > > > > I also assume/hope that we don't want to add a "reg-names" _DSD property either
> > > > > in ACPI to deal with this seamlessly in DT/ACPI (that was done for
> > > > > "interrupt-names"):
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/enumeration.rst?h=v6.18-rc7#n188
> > > >
> > > > Hmm... Why not?
> > >
> > > What's the policy there ?
> >
> > > Half of the ACPI bindings for an interrupt
> > > descriptor are defined in the ACPI specs (ie _CRS) and the other half
> > > (ie "interrupt-names") is documented in the Linux kernel (or are we
> > > documenting this elsewhere ?) ?
> >
> > Yeah, nobody pursued ACPI specification updates / addendum to make it fully
> > official. _De facto_ we have established practice for GPIOs enumeration
> > (as most used resources in the OSes), Linux official for PWM, I²C muxes,
> > multi-functional HW (such as Diolan DLN-2, LJCA), Microsoft defined for
> > so called "USB hardwired" devices, Linux defined for LEDs and GPIO keys,
> > sensor mount matrix as per "most used" cases + DT analogue works just
> > because we have agnostic APIs in IIO to retrieve that. There are maybe
> > more, but don't remember
> >
> > So, I think the practical "policies" are that:
> > - if it's defined in ACPI spec, we use the spec
> > - if there is Microsoft addendum, we rely on what Windows does
> > - WMI, EFI, and other "windoze"-like vendor defined cases
> > - if it makes sense, we establish practice from Linux perspective
> > - the rest, every vendor does what it does
> >
> > That said, for the first two we expect OEMs to follow, for the third one
> > depends, but there are established WMI calls and other more or less "standard"
> > interfaces, so like the first two.
> >
> > For the fourth one (Linux) we do, but living in the expectation that some or
> > more vendors fall to the fifth category and we might need to support that if
> > we want their HW work in Linux.
> >
> > > Or we are saying that "interrupt-names" properties are added by kernel
> > > code _only_ (through software nodes, to make parsing seamless between DT
> > > and ACPI) based on hardcoded name values in drivers ?
> >
> > No, the idea behind software nodes is to "fix" the FW nodes in case the FW
> > description can not be modified (and that might well happen to even DT in some
> > cases AFAIH). So, if some driver hard codes "interrupt-names" we expect that
> > new versions of the FW that support the HW that needs the property will be
> > amended accordingly.
> >
> > "interrupt-names" has been established for ACPI to support a separate SMB alert
> > interrupt. However, I haven't heard any development of that IRL (for real
> > devices in ACPI environment).
> >
> > > I don't think I can grok any example of the latter in the mainline.
> > >
> > > I am asking because I'd need to add something similar shortly to make parsing
> > > of platform devices created out of ACPI static tables easier (I guess we
> > > can postpone discussion till I post the code but I thought I'd ask).
> >
> > Oh, I can go ahead and tell you, try to avoid that. Why?! Whatever,
> > indeed, please Cc me to that, I will be glad to study the case and
> > try to be helpful.
> >
> > (Have you considered DT overlays instead? There is a big pending support for
> > that for _ACPI_ platforms.)
>
> Long story short: we do need to create platform devices out of static
> table (eg ARM64 IORT) entries. Current code parses the table entries and
> try to map the devices IRQs (ie acpi_register_gsi()) when the platform
> device is created. Now, the interrupt controller that device IRQ's is
> routed to might not have probed yet. We have to defer probing and later,
> when the platform driver probes, map the IRQ.
>
> Issue is: for OF nodes and ACPI devices, behind the platform device
> firmware node there is a standard firmware object, so implementing
> fwnode_irq_get() is trivial. For the devices I am talking about,
> the data providing GSI info (hwirq, trigger/polarity) is static
> table specific, so the idea was to stash that data and embed it in
> fwnode_static along with a irq_get() fwnode_operations function
> specific to that piece of data so that device drivers can actually do:
>
> fwnode_irq_get()
>
> on the fwnode _seamlessly_ (if you still do wonder: those platform
> devices created out of static table entries in ACPI in OF are
> of_node(s)).
>
> There is a less convoluted solution (that is what some platform
> drivers in ACPI do today), that is, we pass the static table
> data in pdev->dev.platform_data and each platform_driver parses it differently.
>
> That works but that also means the in the respective device drivers
> OF and ACPI IRQ (and MMIO) parsing differ (which is not necessarily
> a problem I just have to rewrite them all).
Hmm... The parsing inside drivers is quite a custom case. I would avoid doing
it if it's not device specific (I mean if it's not related to the very unique
device or family of the devices which most likely won't appear again in the
future). In other words, I prefer agnostic solutions over custom ones.
> Now - when it comes to "interrupt-names". Some of the device drivers
> I mention do:
>
> eg platform_get_irq_byname_optional()
>
> that expects the IRQ to be mapped and stored in a named platform device resource.
>
> That's easy in DT - for two reasons:
>
> (1) "interrupt-names"
> (2) standard properties behind the of_node
>
> how to do that for fwnodes that aren't backed by either OF nodes or ACPI
> devices (that do use "interrupt-names" _DSD property) is a question.
>
> Mind, the "interrupt-names" thing is a detail in the whole mechanism.
>
> DT overlays to represent in ACPI those static table entries ?
>
> I vividly remember the days ACPI for ARM64 was being merged - that's what
> our crystal ball predicted :)
So, the idea is to translate ACPI static table entries (which comes from IORT)
to the IRQ fwnodes at initialisation (parsing) time?
> This delayed IRQ mapping notwithstanding, I read what you wrote and took
> note. The worry is, this fwnode_*() (on ACPI nodes) interface trickling
> into subsystems where it should not (ie PCI, clocks, regulators) - hopefully
> the respective maintainers are keeping an eye on it.
>
> > > Are we going to do the same for "reg-names" ?
> >
> > If it makes sense and we expect some vendor to follow that _in ACPI_,
> > why not?
> >
> > > Most importantly, what is DT maintainers stance on the matter ?
> >
> > AFAIK They don't care as long as there is a schema provided, accepted and
> > used in DT, if it's ACPI-only thing, then it most likely should be done
> > in ACPI-like way (see above the first two / three items: spec, MS, WMI/EFI).
> >
> > > > > I am sorry I have got more questions than answers here - it would be good
> > > > > to understand where the line is drawn when it comes to OF/ACPI and fwnode
> > > > > heuristics compatibility.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net v3 0/3] net: airoha: Fix airoha_qdma_cleanup_tx_queue() processing
From: Lorenzo Bianconi @ 2026-04-17 6:26 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260416-airoha_qdma_cleanup_tx_queue-fix-net-v3-0-2b69f5788580@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]
> Add missing bits in airoha_qdma_cleanup_tx_queue routine.
> Fix airoha_qdma_cleanup_tx_queue processing errors intorduced in commit
> '3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order
> DMA tx descriptors")'.
>
> ---
> Changes in v3:
> - Move ndesc initialization fix in a dedicated patch.
> - Add patch 2/3 to move entries to queue head in case of DMA mapping
> failure in airoha_dev_xmit().
> - Cosmetics.
> - Link to v2: https://lore.kernel.org/r/20260414-airoha_qdma_cleanup_tx_queue-fix-net-v2-1-875de57cc022@kernel.org
>
> Changes in v2:
> - Move q->ndesc initialization at end of airoha_qdma_init_tx routine in
> order to avoid any possible NULL pointer dereference in
> airoha_qdma_cleanup_tx_queue()
> - Check if q->tx_list is empty in airoha_qdma_cleanup_tx_queue()
> - Link to v1: https://lore.kernel.org/r/20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org
>
> ---
> Lorenzo Bianconi (3):
> net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
> net: airoha: Move entries to queue head in case of DMA mapping failure in airoha_dev_xmit()
> net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
Please drop this version, I will send a new one dropping patch 2/3.
Regards,
Lorenzo
>
> drivers/net/ethernet/airoha/airoha_eth.c | 42 ++++++++++++++++++++++++++------
> 1 file changed, 35 insertions(+), 7 deletions(-)
> ---
> base-commit: 3f20012a3964f487ae1e9ff942e2f35d4e9595bf
> change-id: 20260410-airoha_qdma_cleanup_tx_queue-fix-net-93375f5ee80f
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver
From: andriy.shevchenko @ 2026-04-17 6:35 UTC (permalink / raw)
To: Deep Pani
Cc: Fred-WY Chen (陳威宇),
Lei Xue (薛磊), Mandeep S,
Qingliang Li (黎晴亮), sean.wang@kernel.org,
Yaoy Wang (王瑶瑶), AngeloGioacchino Del Regno,
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Cathy Xu (许华婷),
Shunxi Zhang (章顺喜),
Ye Wang (王叶)
In-Reply-To: <9e802950ae47071bb34bb373419dc89c9add9d0b.camel@mediatek.com>
On Fri, Mar 27, 2026 at 01:33:09PM +0000, Deep Pani wrote:
> Hi Andy,
>
> You mean gpiochip_add_pin_range(), correct?
>
> IIRC, that adds to gpiochip's range, not the range we are using for our
> pinctrl driver.
>
> The range we are utilizing inside our hardware is of the type struct
> pinctrl_gpio_range. There is no callback in gpiochip that handles this
> type of range
I see, thanks for elaboration.
> I also recall that gpiochip_add_data() doesn't initialize the hw but
> rather initializes the gpiochip from the hw data we will provide in
> mtk_build_gpiochip().
It does for IRQ if one specifies an IRQ chip.
> Thus we need a function which will help
> initialize the pinctrl_gpio_range inside our pinctrl driver structure.
> This is why we make the mtk_pinctrl_gpio_range_init function here.
But this sounds like the solution from other end of a stick.
OTOH there are a few drivers that use this approach.
> For the second question, we are keeping it because before ACPI is
> invoked we still need some other pins to be configured, especially if
> different pins have different styles of pull configuration. The method
> we use is to define those configurations in the pinctrl-mt8901.c file
> which determines the gpio ranges and maps pinctrl device to acpi, one
> set of gpio ranges per configuration, for different type of pull
> configurations we have different gpio ranges, this callback helps add
> them into the pinctrl subsystem such that other device maintainers can
> easily leverage that subsystem to add their resources in their _CRS
> calls using the common interfaces.
>
> Thus we need to keep both the functions.
OK.
> On Thu, 2026-03-26 at 12:33 +0000, Fred-WY Chen (陳威宇) wrote:
> > On Wed, 2025-11-26 at 19:06 +0100, Andy Shevchenko wrote:
> > >
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
Please, get rid of this header, it's not compatible with OSS development
process.
> > > On Tue, Nov 25, 2025 at 10:36:34AM +0800, Lei Xue wrote:
> > > > Kernel GPIO subsystem mapping hardware pin number to a different
> > > > range of gpio number. Add gpio-range structure to hold
> > > > the mapped gpio range in pinctrl driver. That enables the kernel
> > > > to search a range of mapped gpio range against a pinctrl device.
> > >
> > > ...
> > >
> > > > static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
> > > > {
> > > > struct gpio_chip *chip = &hw->chip;
> > >
> > > > if (ret < 0)
> > > > return ret;
> > > >
> > > > + mtk_pinctrl_gpio_range_init(hw, chip);
> > > > +
> > > > return 0;
> > >
> > > We have a callback for that in struct gpio_chip. Any reason not to
> > > use it?
> > >
> > > > }
> > >
> > > ...
> > >
> > > > + pinctrl_add_gpio_range(hw->pctrl, &hw->range);
> > >
> > > Not sure if this is needed.
> >
> > Could you please check this and feedback?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver
From: andriy.shevchenko @ 2026-04-17 6:36 UTC (permalink / raw)
To: Deep Pani
Cc: Fred-WY Chen (陳威宇),
Lei Xue (薛磊), Mandeep S,
Qingliang Li (黎晴亮), sean.wang@kernel.org,
Yaoy Wang (王瑶瑶), AngeloGioacchino Del Regno,
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Cathy Xu (许华婷),
Shunxi Zhang (章顺喜),
Ye Wang (王叶)
In-Reply-To: <892cb5455b0306edfb98b3c7df99b88c58e303a9.camel@mediatek.com>
On Fri, Apr 17, 2026 at 06:02:34AM +0000, Deep Pani wrote:
> Any updates from your side?
Sorry for the delayed answer and thanks for pinging me.
Since it was a bit old thread, can you refresh the series (addressing what you
agree with) and send a v2 for review?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net v4 0/2] net: airoha: Fix airoha_qdma_cleanup_tx_queue() processing
From: Lorenzo Bianconi @ 2026-04-17 6:36 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
Add missing bits in airoha_qdma_cleanup_tx_queue routine.
Fix airoha_qdma_cleanup_tx_queue processing errors intorduced in commit
'3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order
DMA tx descriptors")'.
---
Changes in v4:
- Drop patch 2/3 to move entries to queue head in case of DMA mapping
failure in airoha_dev_xmit().
- Link to v3: https://lore.kernel.org/r/20260416-airoha_qdma_cleanup_tx_queue-fix-net-v3-0-2b69f5788580@kernel.org
Changes in v3:
- Move ndesc initialization fix in a dedicated patch.
- Add patch 2/3 to move entries to queue head in case of DMA mapping
failure in airoha_dev_xmit().
- Cosmetics.
- Link to v2: https://lore.kernel.org/r/20260414-airoha_qdma_cleanup_tx_queue-fix-net-v2-1-875de57cc022@kernel.org
Changes in v2:
- Move q->ndesc initialization at end of airoha_qdma_init_tx routine in
order to avoid any possible NULL pointer dereference in
airoha_qdma_cleanup_tx_queue()
- Check if q->tx_list is empty in airoha_qdma_cleanup_tx_queue()
- Link to v1: https://lore.kernel.org/r/20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org
---
Lorenzo Bianconi (2):
net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
drivers/net/ethernet/airoha/airoha_eth.c | 40 +++++++++++++++++++++++++++-----
1 file changed, 34 insertions(+), 6 deletions(-)
---
base-commit: 82c21069028c5db3463f851ae8ac9cc2e38a3827
change-id: 20260410-airoha_qdma_cleanup_tx_queue-fix-net-93375f5ee80f
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* [PATCH net v4 1/2] net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
From: Lorenzo Bianconi @ 2026-04-17 6:36 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-0-e04bcc2c9642@kernel.org>
If queue entry list allocation fails in airoha_qdma_init_tx_queue routine,
airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference
accessing the queue entry array. The issue is due to the early ndesc
initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc
initialization at end of airoha_qdma_init_tx routine.
Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index e1ab15f1ee7d..690bfaf8d7d9 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -954,27 +954,27 @@ static int airoha_qdma_init_tx_queue(struct airoha_queue *q,
dma_addr_t dma_addr;
spin_lock_init(&q->lock);
- q->ndesc = size;
q->qdma = qdma;
q->free_thr = 1 + MAX_SKB_FRAGS;
INIT_LIST_HEAD(&q->tx_list);
- q->entry = devm_kzalloc(eth->dev, q->ndesc * sizeof(*q->entry),
+ q->entry = devm_kzalloc(eth->dev, size * sizeof(*q->entry),
GFP_KERNEL);
if (!q->entry)
return -ENOMEM;
- q->desc = dmam_alloc_coherent(eth->dev, q->ndesc * sizeof(*q->desc),
+ q->desc = dmam_alloc_coherent(eth->dev, size * sizeof(*q->desc),
&dma_addr, GFP_KERNEL);
if (!q->desc)
return -ENOMEM;
- for (i = 0; i < q->ndesc; i++) {
+ for (i = 0; i < size; i++) {
u32 val = FIELD_PREP(QDMA_DESC_DONE_MASK, 1);
list_add_tail(&q->entry[i].list, &q->tx_list);
WRITE_ONCE(q->desc[i].ctrl, cpu_to_le32(val));
}
+ q->ndesc = size;
/* xmit ring drop default setting */
airoha_qdma_set(qdma, REG_TX_RING_BLOCKING(qid),
--
2.53.0
^ permalink raw reply related
* [PATCH net v4 2/2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Lorenzo Bianconi @ 2026-04-17 6:36 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-0-e04bcc2c9642@kernel.org>
Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in
airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to
TX_CPU_IDX to notify the NIC the QDMA TX ring is empty.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 690bfaf8d7d9..6d9f82c677a0 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1039,12 +1039,15 @@ static int airoha_qdma_init_tx(struct airoha_qdma *qdma)
static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
{
- struct airoha_eth *eth = q->qdma->eth;
- int i;
+ struct airoha_qdma *qdma = q->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int i, qid = q - &qdma->q_tx[0];
+ u16 index = 0;
spin_lock_bh(&q->lock);
for (i = 0; i < q->ndesc; i++) {
struct airoha_queue_entry *e = &q->entry[i];
+ struct airoha_qdma_desc *desc = &q->desc[i];
if (!e->dma_addr)
continue;
@@ -1055,8 +1058,33 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
e->dma_addr = 0;
e->skb = NULL;
list_add_tail(&e->list, &q->tx_list);
+
+ /* Reset DMA descriptor */
+ WRITE_ONCE(desc->ctrl, 0);
+ WRITE_ONCE(desc->addr, 0);
+ WRITE_ONCE(desc->data, 0);
+ WRITE_ONCE(desc->msg0, 0);
+ WRITE_ONCE(desc->msg1, 0);
+ WRITE_ONCE(desc->msg2, 0);
+
q->queued--;
}
+
+ if (!list_empty(&q->tx_list)) {
+ struct airoha_queue_entry *e;
+
+ e = list_first_entry(&q->tx_list, struct airoha_queue_entry,
+ list);
+ index = e - q->entry;
+ }
+ /* Set TX_DMA_IDX to TX_CPU_IDX to notify the hw the QDMA TX ring is
+ * empty.
+ */
+ airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid), TX_RING_CPU_IDX_MASK,
+ FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
+ airoha_qdma_rmw(qdma, REG_TX_DMA_IDX(qid), TX_RING_DMA_IDX_MASK,
+ FIELD_PREP(TX_RING_DMA_IDX_MASK, index));
+
spin_unlock_bh(&q->lock);
}
--
2.53.0
^ permalink raw reply related
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