* Re: [PATCH] arm64: kexec: Remove duplicate allocation for trans_pgd
From: Pasha Tatashin @ 2026-04-07 15:02 UTC (permalink / raw)
To: Wang Wensheng
Cc: catalin.marinas, will, mrigendra.chaubey, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260405114231.264761-1-wsw9603@163.com>
On Sun, Apr 5, 2026 at 7:44 AM Wang Wensheng <wsw9603@163.com> wrote:
>
> trans_pgd would be allocated in trans_pgd_create_copy(), so remove the
> duplicate allocation before calling trans_pgd_create_copy().
>
> Fixes: 3744b5280e67 ("arm64: kexec: install a copy of the linear-map")
> Signed-off-by: Wang Wensheng <wsw9603@163.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Thanks,
Pasha
> ---
> arch/arm64/kernel/machine_kexec.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index 239c16e3d02f..c5693a32e49b 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -129,9 +129,6 @@ int machine_kexec_post_load(struct kimage *kimage)
> }
>
> /* Create a copy of the linear map */
> - trans_pgd = kexec_page_alloc(kimage);
> - if (!trans_pgd)
> - return -ENOMEM;
> rc = trans_pgd_create_copy(&info, &trans_pgd, PAGE_OFFSET, PAGE_END);
> if (rc)
> return rc;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-04-07 15:19 UTC (permalink / raw)
To: Peng Fan
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <acs2PAZq2k3zjmDW@shlinux89>
On Tue, Mar 31, 2026 at 10:49:32AM +0800, Peng Fan wrote:
> On Mon, Mar 30, 2026 at 10:22:35AM -0600, Mathieu Poirier wrote:
> >On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
> >> From: Peng Fan <peng.fan@nxp.com>
> >>
> >> Cortex-M[7,33] processors use a fixed reset vector table format:
> >>
> >> 0x00 Initial SP value
> >> 0x04 Reset vector
> >> 0x08 NMI
> >> 0x0C ...
> >> ...
> >> IRQ[n]
> >>
> >> In ELF images, the corresponding layout is:
> >>
> >> reset_vectors: --> hardware reset address
> >> .word __stack_end__
> >> .word Reset_Handler
> >> .word NMI_Handler
> >> .word HardFault_Handler
> >> ...
> >> .word UART_IRQHandler
> >> .word SPI_IRQHandler
> >> ...
> >>
> >> Reset_Handler: --> ELF entry point address
> >> ...
> >>
> >> The hardware fetches the first two words from reset_vectors and populates
> >> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> >> Reset_Handler.
> >>
> >> However, the ELF entry point does not always match the hardware reset
> >> address. For example, on i.MX94 CM33S:
> >>
> >> ELF entry point: 0x0ffc211d
> >> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
> >>
> >
> >But why? Why can't the ELF image be set to the right reset base?
>
> Per zephyr general link script[1]:
> ENTRY(CONFIG_KERNEL_ENTRY)
>
> CONFIG_KERNEL_ENTRY(_start) is the first instruction that Cortex-M starts to
> execute.
>
> config KERNEL_ENTRY
> string "Kernel entry symbol"
> default "__start"
> help
> Code entry symbol, to be set at linking phase.
>
> The hardware reset base is different: it is the address where the hardware
> fetches the initial MSP and PC values from the vector table. Hardware uses
> this base to initialize the stack pointer and program counter, and only then
> does the Cortex‑M begin execution at the reset handler.
That part is clear.
>
> Aligning the ELF entry point with the hardware reset base on Cortex‑M systems
> is possible, but it comes with several risks.
I'm not asking to align the ELF entry point with the hardware reset base. All I
want is to have the correct start address embedded in the ELF file to avoid
having to use a mask.
> 1, Semantic mismatch (ELF vs. hardware behavior)
> 2, Debuggers may attempt to set breakpoints or start execution at the entry symbol
>
> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc1/source/include/zephyr/arch/arm/cortex_m/scripts/linker.ld#L103
>
> Regards
> Peng.
> >
^ permalink raw reply
* Re: [PATCH 1/4] exec: inherit HWCAPs from the parent process
From: Mark Rutland @ 2026-04-07 15:23 UTC (permalink / raw)
To: Andrei Vagin
Cc: Will Deacon, Kees Cook, Andrew Morton, Marek Szyprowski,
Cyrill Gorcunov, Mike Rapoport, Alexander Mikhalitsyn,
linux-kernel, linux-fsdevel, linux-mm, criu, Catalin Marinas,
linux-arm-kernel, Chen Ridong, Christian Brauner,
David Hildenbrand, Eric Biederman, Lorenzo Stoakes, Michal Koutny,
Alexander Mikhalitsyn, Linux API
In-Reply-To: <CAEWA0a7AZiuy1F+0LDxtEtJpdu=zA-RKhPb1wcDMpy2tSMFO5g@mail.gmail.com>
On Fri, Mar 27, 2026 at 05:21:26PM -0700, Andrei Vagin wrote:
> Hi Mark,
>
> I understand all these points and they are valid. However, as I
> mentioned, we are not trying to introduce a mechanism that will strictly
> enforce feature sets for every container. While we would like to have
> that functionality, as you and will mentioned, it would require
> substantially more complexity to address, and maintainers would unlikely
> to pick up that complexity.
The crux of my complaint here is that unless you do that (to some
degree), this is not going to work reliably, even with the constraints
you outline.
Further, I disagree with your proposed solution of pushing more
constraints onto userspace (to also consider HWCAPs as overriding other
mechainsms, etc).
I think that as-is, the approach is flawed.
> Even masking ID registers on a per-container basis would introduce
> extra complexity that could make architecture maintainers unhappy.
> There were a few attempts to introduce container CPUID masking on
> x86_64 in the past.
> In CRIU, we are not aiming to handle every possible workload. Our goal
> is to target workloads where developers are ready to cooperate and
> willing to make adjustments to be C/R compatible. The goal here is to
> provide developers with clear instructions on what they can do to ensure
> their applications are C/R compatible. When I say "workloads", I mean
> this in a broad sense. A container might pack a set of tools with
> different runtimes (Go, Java, libc-based). All these runtimes should
> detect only allowed features.
I do not think that arbitrary applications (and libraries!) should have
to pick up additional constraints that are unnecessary without CRIU,
especially where that goes against deliberate design decisions (e.g.
features in arm64's HINT instruction space, which are designed to be
usable in fast paths WITHOUT needing explicit checks of things like
HWCAPs). Note that those typically *do* have kernel controls.
I think there's a much larger problem space than you anticipate, and
adding an incomplete solution now is just going to introduce a
maintenance burden.
> Returning to the subject of this patchset: this series extends the role
> of hwcaps. With this change, we would establish that hwcaps is the
> "source of truth" for which features an application can safely use. Any
> other features available on the current CPU would not be guaranteed to
> remain available after migration to another machine.
>
> After this discussion, I found that the current version missed one major
> thing: there should be a signal indicating that hwcaps must be used for
> feature detection. Since we will need to integrate this interface into
> libc, Go, and other runtimes, they definitely should not rely just on
> hwcaps by default, especially in the early stages. This can be solved
> via the prctl command. Libraries like libc would call
> prctl(PR_USER_HWCAP_ENABLED). If this returns true, the runtime knows
> that only the features explicitly listed in hwcaps should be used.
I do not think we should be pushing that shape of constraint onto
userspace.
> You are right, the controlled feature set will be limited to features
> the kernel knows about. And yes, we would need to report CPU features in
> hwcaps even if the kernel isn't directly involved in handling them.
To be clear, that is not what I am arguing.
As I mentioned before, the way this works on arm64 is that the kernel
only exposes what it is aware of, even in the ID regs accessible to
userspace. We usually *can* hide features, and do that for cases of
mismatched big.LITTLE, virtual machines, etc.
> Honestly, I am not certain if this is the "right" interface for that,
> and I would be happy to consider other ideas. I understand that these
> hwcaps will not work right out of the box, but we need a way to solve
> this problem. Having a centralized API for CPU/kernel feature detection
> seems like the right direction.
I think that for better or worse the approach you are tkaing here simply
does not solve enough of the problem to actually be worthwhile.
> As for signal frame size and extended states like SVE/SME, we aware
> about this problem. However, it is partly mitigated by the fact that if
> an application does not use some features, those states are not placed
> in the signal frame.
That is not true. The kernel can and will create signal frames for
architectural state that a task might never have touched.
Generally arm64 creates signal frames for features when the feature
*exists*, regardless of whether the task has actively manipulated the
relevant state. For example, on systems with SVE a trivial SVE signal
frame gets created even if a task only uses the FPSIMD registers, and on
systms with SME a TPIDR2 signal frame gets created even if the task has
never read/written TPIDR2.
When restoring, an unrecognised signal frame is treated as invalid, and
we can require that certain signal frames are present.
> In the future, when we construct/reload a signal frame, we could look
> at a process feature set for a process and generate a frame according
> to those features...
When you say 'we' here, are you talking about within the kernel, or
within the userspace C/R mechanism?
Mark.
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
From: Marek Vasut @ 2026-04-07 15:26 UTC (permalink / raw)
To: linux-arm-kernel, Frank Li
Cc: Christoph Niedermaier, Conor Dooley, Fabio Estevam,
Krzysztof Kozlowski, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, devicetree, imx, kernel, linux-kernel
In-Reply-To: <20260326044411.222907-1-marex@nabladev.com>
On 3/26/26 5:43 AM, Marek Vasut wrote:
> Add DT overlays to support DH i.MX8M Plus DHCOM SoM variants and carrier
> board expansion modules. The following DT overlays are implemented:
> - SoM:
> - DH 660-x00 SoM with 1xRMII PHY
> - DH 660-x00 SoM with 2xRMII PHY
> - PDK2:
> - DH 505-200 Display board in edge connector X12 via direct LVDS
> - DH 531-100 SPI/I2C board in header X21
> - DH 531-200 SPI/I2C board in header X22
> - DH 560-200 Display board in edge connector X12
> - PDK3:
> - DH 505-200 Display board in edge connector X36 via direct LVDS
> - DH 531-100 SPI/I2C board in header X40
> - DH 531-200 SPI/I2C board in header X41
> - DH 560-300 Display board in edge connector X36
> - EA muRata 2AE M.2 A/E-Key card in connector X20
> - NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X31
> - NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X29
> - PicoITX:
> - DH 626-100 Display board in edge connector X2
Hello Frank,
I know I was sending quite a few DTOs recently. Is this set still on
your review list, or was this one missed ?
Thank you for reviewing the DTOs so actively, it really helps a lot !
^ permalink raw reply
* [PATCH] arm64: rsi: use linear-map alias for realm config buffer
From: Aneesh Kumar K.V (Arm) @ 2026-04-07 15:29 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Aneesh Kumar K.V (Arm), Catalin Marinas, Will Deacon,
Suzuki K Poulose, Steven Price, Gavin Shan
rsi_get_realm_config() passes its argument to virt_to_phys(), but
&config is a kernel image address and not a linear-map alias.
On arm64 this triggers the below warning:
virt_to_phys used for non-linear address: (____ptrval____) (config+0x0/0x1000)
WARNING: arch/arm64/mm/physaddr.c:15 at __virt_to_phys+0x50/0x70, CPU#0: swapper/0
Modules linked in:
.....
Hardware name: linux,dummy-virt (DT)
pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __virt_to_phys+0x50/0x70
lr : __virt_to_phys+0x4c/0x70
.....
......
Call trace:
__virt_to_phys+0x50/0x70 (P)
arm64_rsi_init+0xa0/0x1b8
setup_arch+0x13c/0x1a0
start_kernel+0x68/0x398
__primary_switched+0x88/0x90
Pass lm_alias(&config) instead so the RSI call uses the linear-map
alias of the same buffer and avoids the boot-time warning.
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Gavin Shan <gshan@redhat.com>
---
arch/arm64/kernel/rsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
index 9e846ce4ef9c..92160f2e57ff 100644
--- a/arch/arm64/kernel/rsi.c
+++ b/arch/arm64/kernel/rsi.c
@@ -145,7 +145,7 @@ void __init arm64_rsi_init(void)
return;
if (!rsi_version_matches())
return;
- if (WARN_ON(rsi_get_realm_config(&config)))
+ if (WARN_ON(rsi_get_realm_config(lm_alias(&config))))
return;
prot_ns_shared = __phys_to_pte_val(BIT(config.ipa_bits - 1));
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/6] perf arm_spe: Handle missing CPU IDs
From: Leo Yan @ 2026-04-07 15:30 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-2-55d3ef997c48@linaro.org>
On Tue, Apr 07, 2026 at 03:05:16PM +0100, James Clark wrote:
> Don't call strtol() with a null pointer to avoid undefined behavior.
>
> I'm not sure of the exact scenario for missing CPU IDs but I don't think
> it happens in practice. SPE decoding can continue without them with
> reduced functionality, but print an error message anyway.
>
> Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Leo Yan <leo.yan@arm.com>
> ---
> tools/perf/util/arm-spe.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> index 7447b000f9cd..fc11f32e4911 100644
> --- a/tools/perf/util/arm-spe.c
> +++ b/tools/perf/util/arm-spe.c
> @@ -968,16 +968,23 @@ static int arm_spe__get_midr(struct arm_spe *spe, int cpu, u64 *midr)
>
> pr_warning_once("Old SPE metadata, re-record to improve decode accuracy\n");
> cpuid = perf_env__cpuid(perf_session__env(spe->session));
> + if (!cpuid)
> + goto err;
> +
> *midr = strtol(cpuid, NULL, 16);
> return 0;
> }
>
> metadata = arm_spe__get_metadata_by_cpu(spe, cpu);
> if (!metadata)
> - return -EINVAL;
> + goto err;
>
> *midr = metadata[ARM_SPE_CPU_MIDR];
> return 0;
> +
> +err:
> + pr_err("Failed to get MIDR for CPU %d\n", cpu);
> + return -EINVAL;
> }
>
> static void arm_spe__synth_ds(struct arm_spe_queue *speq,
>
> --
> 2.34.1
>
>
^ permalink raw reply
* [PATCH v4 2/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-04-07 15:35 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260407153511.4250-1-gakula@marvell.com>
The CN20K DRAM Subsystem exposes eight programmable
performance counters and two fixed counters for DDR
read and write traffic. Software selects events for
the programmable counters from traffic at the DDR PHY
interface, the CHI interconnect, or inside the DDR controller.
Add CN20K register offsets, event maps, and sysfs attributes;
match the device via OF (marvell,cn20k-ddr-pmu) and ACPI (MRVL000B).
Represent the SoC variant in platform data with bit flags so
CN20K can reuse the CN10K PMU code path where appropriate.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
drivers/perf/marvell_cn10k_ddr_pmu.c | 187 ++++++++++++++++++++++++---
1 file changed, 171 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/marvell_cn10k_ddr_pmu.c b/drivers/perf/marvell_cn10k_ddr_pmu.c
index 72ac17efd846..7e2e1823b009 100644
--- a/drivers/perf/marvell_cn10k_ddr_pmu.c
+++ b/drivers/perf/marvell_cn10k_ddr_pmu.c
@@ -13,31 +13,43 @@
#include <linux/hrtimer.h>
#include <linux/acpi.h>
#include <linux/platform_device.h>
+#include <linux/bits.h>
+
+/* SoC variant flags for struct ddr_pmu_platform_data (mutually exclusive in pdata) */
+#define IS_CN10K BIT(0)
+#define IS_ODY BIT(1)
+#define IS_CN20K BIT(2)
/* Performance Counters Operating Mode Control Registers */
#define CN10K_DDRC_PERF_CNT_OP_MODE_CTRL 0x8020
#define ODY_DDRC_PERF_CNT_OP_MODE_CTRL 0x20020
+#define CN20K_DDRC_PERF_CNT_OP_MODE_CTRL 0x20000
#define OP_MODE_CTRL_VAL_MANUAL 0x1
/* Performance Counters Start Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_START_OP_CTRL 0x8028
#define ODY_DDRC_PERF_CNT_START_OP_CTRL 0x200A0
+#define CN20K_DDRC_PERF_CNT_START_OP_CTRL 0x20080
#define START_OP_CTRL_VAL_START 0x1ULL
#define START_OP_CTRL_VAL_ACTIVE 0x2
/* Performance Counters End Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_END_OP_CTRL 0x8030
#define ODY_DDRC_PERF_CNT_END_OP_CTRL 0x200E0
+#define CN20K_DDRC_PERF_CNT_END_OP_CTRL 0x200C0
#define END_OP_CTRL_VAL_END 0x1ULL
/* Performance Counters End Status Registers */
#define CN10K_DDRC_PERF_CNT_END_STATUS 0x8038
#define ODY_DDRC_PERF_CNT_END_STATUS 0x20120
+#define CN20K_DDRC_PERF_CNT_END_STATUS 0x20100
#define END_STATUS_VAL_END_TIMER_MODE_END 0x1
/* Performance Counters Configuration Registers */
#define CN10K_DDRC_PERF_CFG_BASE 0x8040
#define ODY_DDRC_PERF_CFG_BASE 0x20160
+#define CN20K_DDRC_PERF_CFG_BASE 0x20140
+#define CN20K_DDRC_PERF_CFG1_BASE 0x20180
/* 8 Generic event counter + 2 fixed event counters */
#define DDRC_PERF_NUM_GEN_COUNTERS 8
@@ -61,6 +73,23 @@
* DO NOT change these event-id numbers, they are used to
* program event bitmap in h/w.
*/
+
+/* CN20K specific events */
+#define EVENT_PERF_OP_IS_RD16 61
+#define EVENT_PERF_OP_IS_RD32 60
+#define EVENT_PERF_OP_IS_WR16 59
+#define EVENT_PERF_OP_IS_WR32 58
+#define EVENT_OP_IS_ENTER_DSM 44
+#define EVENT_OP_IS_RFM 43
+
+#define EVENT_CN20K_OP_IS_TCR_MRR 50
+#define EVENT_CN20K_OP_IS_DQSOSC_MRR 49
+#define EVENT_CN20K_OP_IS_DQSOSC_MPC 48
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR 47
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD 46
+#define EVENT_CN20K_OP_IS_ZQLATCH 21
+#define EVENT_CN20K_OP_IS_ZQSTART 22
+
#define EVENT_DFI_CMD_IS_RETRY 61
#define EVENT_RD_UC_ECC_ERROR 60
#define EVENT_RD_CRC_ERROR 59
@@ -87,6 +116,9 @@
#define EVENT_OP_IS_SPEC_REF 41
#define EVENT_OP_IS_CRIT_REF 40
#define EVENT_OP_IS_REFRESH 39
+#define EVENT_OP_IS_CAS_WCK_SUS 38
+#define EVENT_OP_IS_CAS_WS_OFF 37
+#define EVENT_OP_IS_CAS_WS 36
#define EVENT_OP_IS_ENTER_MPSM 35
#define EVENT_OP_IS_ENTER_POWERDOWN 31
#define EVENT_OP_IS_ENTER_SELFREF 27
@@ -183,8 +215,8 @@ struct ddr_pmu_platform_data {
u64 cnt_freerun_clr;
u64 cnt_value_wr_op;
u64 cnt_value_rd_op;
- bool is_cn10k;
- bool is_ody;
+ u64 cfg1_base;
+ unsigned int silicon_flags; /* IS_CN10K, IS_ODY, or IS_CN20K */
};
static ssize_t cn10k_ddr_pmu_event_show(struct device *dev,
@@ -336,6 +368,80 @@ static struct attribute *odyssey_ddr_perf_events_attrs[] = {
NULL
};
+static struct attribute *cn20k_ddr_perf_events_attrs[] = {
+ /* Programmable */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_or_wr_access, EVENT_HIF_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_wr_access, EVENT_HIF_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_access, EVENT_HIF_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rmw_access, EVENT_HIF_RMW),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_pri_rdaccess, EVENT_HIF_HI_PRI_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rd_bypass_access, EVENT_READ_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_act_bypass_access, EVENT_ACT_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_wr_data_access,
+ EVENT_DFI_WR_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_rd_data_access,
+ EVENT_DFI_RD_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hpri_sched_rd_crit_access,
+ EVENT_HPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_lpri_sched_rd_crit_access,
+ EVENT_LPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_wr_trxn_crit_access,
+ EVENT_WR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_active_access, EVENT_OP_IS_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_or_wr_access,
+ EVENT_OP_IS_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_active_access,
+ EVENT_OP_IS_RD_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_read, EVENT_OP_IS_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_write, EVENT_OP_IS_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_mwr, EVENT_OP_IS_MWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge, EVENT_OP_IS_PRECHARGE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_rdwr,
+ EVENT_PRECHARGE_FOR_RDWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_other,
+ EVENT_PRECHARGE_FOR_OTHER),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rdwr_transitions, EVENT_RDWR_TRANSITIONS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write_combine, EVENT_WRITE_COMBINE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_war_hazard, EVENT_WAR_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_raw_hazard, EVENT_RAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_waw_hazard, EVENT_WAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_selfref, EVENT_OP_IS_ENTER_SELFREF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_powerdown,
+ EVENT_OP_IS_ENTER_POWERDOWN),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws, EVENT_OP_IS_CAS_WS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws_off, EVENT_OP_IS_CAS_WS_OFF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_wck_sus, EVENT_OP_IS_CAS_WCK_SUS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_refresh, EVENT_OP_IS_REFRESH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_crit_ref, EVENT_OP_IS_CRIT_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_spec_ref, EVENT_OP_IS_SPEC_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_load_mode, EVENT_OP_IS_LOAD_MODE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rfm, EVENT_OP_IS_RFM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_dsm, EVENT_OP_IS_ENTER_DSM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_cycles, EVENT_DFI_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_rd,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_wr,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mpc, EVENT_CN20K_OP_IS_DQSOSC_MPC),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mrr, EVENT_CN20K_OP_IS_DQSOSC_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_tcr_mrr, EVENT_CN20K_OP_IS_TCR_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqstart, EVENT_CN20K_OP_IS_ZQSTART),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqlatch, EVENT_CN20K_OP_IS_ZQLATCH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read16, EVENT_PERF_OP_IS_RD16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read32, EVENT_PERF_OP_IS_RD32),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write16, EVENT_PERF_OP_IS_WR16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write32, EVENT_PERF_OP_IS_WR32),
+ /* Free run event counters */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_reads, EVENT_DDR_READS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_writes, EVENT_DDR_WRITES),
+ NULL
+};
+
+static struct attribute_group cn20k_ddr_perf_events_attr_group = {
+ .name = "events",
+ .attrs = cn20k_ddr_perf_events_attrs,
+};
+
static struct attribute_group odyssey_ddr_perf_events_attr_group = {
.name = "events",
.attrs = odyssey_ddr_perf_events_attrs,
@@ -393,6 +499,13 @@ static const struct attribute_group *odyssey_attr_groups[] = {
NULL
};
+static const struct attribute_group *cn20k_attr_groups[] = {
+ &cn20k_ddr_perf_events_attr_group,
+ &cn10k_ddr_perf_format_attr_group,
+ &cn10k_ddr_perf_cpumask_attr_group,
+ NULL
+};
+
/* Default poll timeout is 100 sec, which is very sufficient for
* 48 bit counter incremented max at 5.6 GT/s, which may take many
* hours to overflow.
@@ -412,7 +525,7 @@ static int ddr_perf_get_event_bitmap(int eventid, u64 *event_bitmap,
switch (eventid) {
case EVENT_DFI_PARITY_POISON ...EVENT_DFI_CMD_IS_RETRY:
- if (!ddr_pmu->p_data->is_ody) {
+ if (!(ddr_pmu->p_data->silicon_flags & IS_ODY)) {
err = -EINVAL;
break;
}
@@ -524,9 +637,9 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
int counter, bool enable)
{
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
u64 ctrl_reg = pmu->p_data->cnt_op_mode_ctrl;
const struct ddr_pmu_ops *ops = pmu->ops;
- bool is_ody = pmu->p_data->is_ody;
u32 reg;
u64 val;
@@ -546,7 +659,7 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
writeq_relaxed(val, pmu->base + reg);
- if (is_ody) {
+ if (silicon_flags & IS_ODY) {
if (enable) {
/*
* Setup the PMU counter to work in
@@ -621,6 +734,7 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
{
struct cn10k_ddr_pmu *pmu = to_cn10k_ddr_pmu(event->pmu);
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
const struct ddr_pmu_ops *ops = pmu->ops;
struct hw_perf_event *hwc = &event->hw;
u8 config = event->attr.config;
@@ -642,10 +756,17 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
if (counter < DDRC_PERF_NUM_GEN_COUNTERS) {
/* Generic counters, configure event id */
reg_offset = DDRC_PERF_CFG(p_data->cfg_base, counter);
- ret = ddr_perf_get_event_bitmap(config, &val, pmu);
- if (ret)
- return ret;
+ if (silicon_flags & IS_CN20K) {
+ val = (1ULL << (config - 1));
+ if (config == EVENT_CN20K_OP_IS_ZQSTART ||
+ config == EVENT_CN20K_OP_IS_ZQLATCH)
+ reg_offset = DDRC_PERF_CFG(p_data->cfg1_base, counter);
+ } else {
+ ret = ddr_perf_get_event_bitmap(config, &val, pmu);
+ if (ret)
+ return ret;
+ }
writeq_relaxed(val, pmu->base + reg_offset);
} else {
/* fixed event counter, clear counter value */
@@ -952,7 +1073,25 @@ static const struct ddr_pmu_platform_data cn10k_ddr_pmu_pdata = {
.cnt_freerun_clr = 0,
.cnt_value_wr_op = CN10K_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = CN10K_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_cn10k = TRUE,
+ .silicon_flags = IS_CN10K,
+};
+
+static const struct ddr_pmu_platform_data cn20k_ddr_pmu_pdata = {
+ .counter_overflow_val = 0,
+ .counter_max_val = GENMASK_ULL(63, 0),
+ .cnt_base = ODY_DDRC_PERF_CNT_VALUE_BASE,
+ .cfg_base = CN20K_DDRC_PERF_CFG_BASE,
+ .cfg1_base = CN20K_DDRC_PERF_CFG1_BASE,
+ .cnt_op_mode_ctrl = CN20K_DDRC_PERF_CNT_OP_MODE_CTRL,
+ .cnt_start_op_ctrl = CN20K_DDRC_PERF_CNT_START_OP_CTRL,
+ .cnt_end_op_ctrl = CN20K_DDRC_PERF_CNT_END_OP_CTRL,
+ .cnt_end_status = CN20K_DDRC_PERF_CNT_END_STATUS,
+ .cnt_freerun_en = 0,
+ .cnt_freerun_ctrl = ODY_DDRC_PERF_CNT_FREERUN_CTRL,
+ .cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
+ .cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
+ .cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
+ .silicon_flags = IS_CN20K,
};
#endif
@@ -979,7 +1118,7 @@ static const struct ddr_pmu_platform_data odyssey_ddr_pmu_pdata = {
.cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
.cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_ody = TRUE,
+ .silicon_flags = IS_ODY,
};
#endif
@@ -989,8 +1128,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
struct cn10k_ddr_pmu *ddr_pmu;
struct resource *res;
void __iomem *base;
- bool is_cn10k;
- bool is_ody;
+ unsigned int silicon_flags;
char *name;
int ret;
@@ -1014,10 +1152,9 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
ddr_pmu->base = base;
ddr_pmu->p_data = dev_data;
- is_cn10k = ddr_pmu->p_data->is_cn10k;
- is_ody = ddr_pmu->p_data->is_ody;
+ silicon_flags = ddr_pmu->p_data->silicon_flags;
- if (is_cn10k) {
+ if (silicon_flags & IS_CN10K) {
ddr_pmu->ops = &ddr_pmu_ops;
/* Setup the PMU counter to work in manual mode */
writeq_relaxed(OP_MODE_CTRL_VAL_MANUAL, ddr_pmu->base +
@@ -1039,7 +1176,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
- if (is_ody) {
+ if (silicon_flags & IS_ODY) {
ddr_pmu->ops = &ddr_pmu_ody_ops;
ddr_pmu->pmu = (struct pmu) {
@@ -1056,6 +1193,22 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
+ if (silicon_flags & IS_CN20K) {
+ ddr_pmu->ops = &ddr_pmu_ody_ops;
+
+ ddr_pmu->pmu = (struct pmu) {
+ .module = THIS_MODULE,
+ .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
+ .task_ctx_nr = perf_invalid_context,
+ .attr_groups = cn20k_attr_groups,
+ .event_init = cn10k_ddr_perf_event_init,
+ .add = cn10k_ddr_perf_event_add,
+ .del = cn10k_ddr_perf_event_del,
+ .start = cn10k_ddr_perf_event_start,
+ .stop = cn10k_ddr_perf_event_stop,
+ .read = cn10k_ddr_perf_event_update,
+ };
+ }
/* Choose this cpu to collect perf data */
ddr_pmu->cpu = raw_smp_processor_id();
@@ -1098,6 +1251,7 @@ static void cn10k_ddr_perf_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id cn10k_ddr_pmu_of_match[] = {
{ .compatible = "marvell,cn10k-ddr-pmu", .data = &cn10k_ddr_pmu_pdata },
+ { .compatible = "marvell,cn20k-ddr-pmu", .data = &cn20k_ddr_pmu_pdata },
{ },
};
MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
@@ -1107,6 +1261,7 @@ MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
static const struct acpi_device_id cn10k_ddr_pmu_acpi_match[] = {
{"MRVL000A", (kernel_ulong_t)&cn10k_ddr_pmu_pdata },
{"MRVL000C", (kernel_ulong_t)&odyssey_ddr_pmu_pdata},
+ {"MRVL000B", (kernel_ulong_t)&cn20k_ddr_pmu_pdata},
{},
};
MODULE_DEVICE_TABLE(acpi, cn10k_ddr_pmu_acpi_match);
--
2.25.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: perf: marvell: Add CN20K DDR PMU binding
From: Geetha sowjanya @ 2026-04-07 15:35 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260407153511.4250-1-gakula@marvell.com>
Marvell CN20K SoCs integrate a DDR Performance Monitoring Unit (PMU)
associated with the DDR controller. The block provides hardware counters
to monitor DDR traffic and performance events and is accessed via a
dedicated MMIO region.
The CN20K DDR PMU is functionally equivalent to the CN10K DDR PMU, with
minor register offset differences. This binding documents the CN20K
variant and introduces a specific compatible string to allow software
to distinguish between the two implementations.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
.../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39 +++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr-pmu.yaml
diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr-pmu.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr-pmu.yaml
new file mode 100644
index 000000000000..78a0cd9a7b1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr-pmu.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell CN20K DDR performance monitor
+
+description:
+ Performance Monitoring Unit (PMU) for the DDR controller
+ in Marvell CN20K SoCs.
+
+maintainers:
+ - Geetha sowjanya <gakula@marvell.com>
+
+properties:
+ compatible:
+ const: marvell,cn20k-ddr-pmu
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ddr-pmu@c200000000 {
+ compatible = "marvell,cn20k-ddr-pmu";
+ reg = <0xc200 0x00000000 0x0 0x100000>;
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v4 0/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-04-07 15:35 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
This series adds support for the DDR Performance Monitoring Unit (PMU)
present in Marvell CN20K SoCs.
The DDR PMU is part of the DRAM Subsystem (DSS) and provides hardware
counters to monitor DDR traffic and performance events. The block
implements eight programmable counters and two fixed-function counters
tracking DDR read and write activity, and is accessed via a dedicated
MMIO region.
CN20K is the successor to CN10K, and the DDR PMU hardware is functionally
equivalent to the CN10K implementation, with only minor differences in
register offsets and event mappings. To allow software to distinguish
between the two silicon variants, this series introduces a specific
"marvell,cn20k-ddr-pmu" compatible and extends the existing
marvell_cn10k_ddr_pmu driver to handle CN20K via variant-specific data.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Chnages in v3:
- Expanded cover letter and commit message to better describe the DDR PMU
hardware and its relationship to CN10K
- Fixed the file name.
Changes in v2:
- Fixed YAML syntax error triggered by a tab character in the examples
section, which caused dt_binding_check to fail.
Changes in v1:
- Added a description field to the binding.
- Simplified the compatible property using 'const' instead of 'items/enum'.
- Updated the example node name to include a unit-address matching the reg base.
Geetha sowjanya (2):
dt-bindings: perf: marvell: Document CN20K DDR PMU
perf: marvell: Add CN20K DDR PMU support
.../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39 ++++
drivers/perf/marvell_cn10k_ddr_pmu.c | 187 ++++++++++++++++--
2 files changed, 210 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr-pmu.yaml
--
2.25.1
^ permalink raw reply
* Re: [PATCH v2 3/6] perf arm_spe: Store MIDR in arm_spe_pkt
From: Leo Yan @ 2026-04-07 15:41 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-3-55d3ef997c48@linaro.org>
On Tue, Apr 07, 2026 at 03:05:17PM +0100, James Clark wrote:
> The MIDR will affect printing of arm_spe_pkts, so store a copy of it
> there. Technically it's constant for each decoder, but there is no
> decoder when doing a raw dump, so it has to be stored in every packet.
> It will only be used in raw dump mode and not in normal decoding for
> now, but to avoid any surprises, set MIDR properly on the decoder too.
>
> Having both the MIDR and the arm_spe_pkt (which has a copy of it) in the
> decoder seemed a bit weird, so remove arm_spe_pkt from the decoder. The
> packet is only short lived anyway so probably shouldn't have been there
> in the first place.
>
> Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH net-next v9 1/4] net: stmmac: Add DW25GMAC support in stmmac core driver
From: Russell King (Oracle) @ 2026-04-07 15:42 UTC (permalink / raw)
To: Jitendra Vegiraju
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rohan.g.thomas, linux-kernel,
linux-stm32, linux-arm-kernel, bpf, andrew+netdev, horms, sdf, me,
siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <adUQHHBD0d3p1OSI@shell.armlinux.org.uk>
On Tue, Apr 07, 2026 at 03:09:32PM +0100, Russell King (Oracle) wrote:
> Not withstanding my comment about the other Synopsys xlgmac driver that
> we have in the kernel...
>
> On Thu, Apr 02, 2026 at 02:36:26PM -0700, Jitendra Vegiraju wrote:
> > From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
> >
> > The DW25GMAC introduced a new DMA architecture called Hyper-DMA (HDMA) for
> > virtualization scalability. This is realized by decoupling physical DMA
> > channels(PDMA) from potentially large number of virtual DMA channels(VDMA).
> > The VDMAs provide software abstraction to driver that map to PDMAs for
> > frame transmission and reception.
> > Since 25GMAC is a derivative of XGMAC, majority of IP is common to both.
> >
> > To add support for the HDMA in 25GMAC, a new instance of dma_ops,
> > dw25gmac400_dma_ops is introduced.
> > To support the current needs, a simple one-to-one mapping of dw25gmac's
> > logical VDMA (channel) to TC to PDMAs is used. Most of the other dma
> > operation functions in existing dwxgamc2_dma.c file are reused whereever
>
> Typo: dwxgmac2_dma.c
>
> > applicable.
> > Added setup function for DW25GMAC's stmmac_hwif_entry in stmmac core.
>
> In a previous review, I questioned the use of DWMAC_CORE_25GMAC and
> asked about its version numberspace. I believe you indicated that the
> version numberspace is the same as the existing XGMAC core.
>
> I'm going to question the value of adding DWMAC_CORE_25GMAC.
>
> 1. What is the value of splitting DWMAC_CORE_25GMAC from
> DWMAC_CORE_XGMAC given that it's in the same versioning numberspace
> as XGMAC, and most tests (via dwmac_is_xgmac()) test for XGMAC or
> 25GMAC?
>
> 2. Have you reviewed all the places that explicitly test for
> DWMAC_CORE_XGMAC, looking at their "false" paths (for non-XGMAC
> cores) to determine whether they are suitable? For example:
>
> if (priv->plat->core_type == DWMAC_CORE_XGMAC)
> ndev->max_mtu = XGMAC_JUMBO_LEN;
> else if (priv->plat->enh_desc || priv->synopsys_id >= DWMAC_CORE_4_00)
> ndev->max_mtu = JUMBO_LEN;
> else
> ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
>
> XGMAC can handle a max MTU of 16368, but with your code using
> DWMAC_CORE_25GMAC, we fall back to the next test, which tests the
> IP version against 0x40, and uses a max MTU of 9000. Given that
> DWMAC_CORE_4_00 is a different "version number space" this seems
> wrong.
This is actually wrong - for DWMAC_CORE_25GMAC with a synopsys_id
less than 0x40, this will fall back to SKB_MAX_HEAD(NET_SKB_PAD +
NET_IP_ALIGN) which is as good as "pluck a number out of the air
and watch the driver fall over if you increase the MTU to maximum".
max_mtu ends up being dependent on the system page size, not on any
hardware limitation, which is garbage.
> 3. Looking at the MDIO code, this looks very wrong if you're
> introducing DWMAC_CORE_25GMAC. Have you tested MDIO accesses?
>
> dwxgmac2_setup() is called for DWMAC_CORE_XGMAC core-type. In
> stmmac_mdio_register(), DWMAC_CORE_XGMAC uses different functions
> for MDIO bus access for C22 and C45 from other cores - it uses the
> stmmac_xgmac2_mdio_* functions.
>
> These use stmmac_xgmac2_c45_format() and stmmac_xgmac2_c22_format()
> to format the register values which do not depend on mii.*_mask, but
> do use mii.address and mii.data for the register offsets. Thus, is
> there any point to setting mii.addr_mask and mii.reg_mask ?
>
> For non-DWMAC_CORE_XGMAC cores, we fall back to the stmmac_mdio_*()
> functions, which for non-DWMAC_CORE_GMAC4 will only support Clause
> 22 access, not Clause 45 - which would be very strange for a 25G
> core.
>
> 4. What about the feature printing in
> stmmac_main.c::stmmac_dma_cap_show() ?
>
> 5. What about similar tests in stmmac_est.c and stmmac_ethtool.c ?
Another issue that needs to be looked into is all the tests that
check priv->synopsys_id without checking the core_type. I'm already
concerned that many of these are wrong.
I have some patches now that rename synopsys_id to snpsver (it's really
the Synopsys IP version field which is BCD of the major version and
first digit of the minor version, not some random ID that identifies
the core.)
From what I've ascertained so far:
GMAC100 cores do not have a readable snpsver number, thus this
will be zero.
GMAC cores generally have a snpsver number less than 0x40.
GMAC4 cores may have a version number that overlaps GMAC cores
(see first entry for DWMAC_CORE_GMAC4).
XGMAC and XLGMAC cores each have an entirely separate IP version
number space from GMAC and GMAC4, which are distinguished by their
respective userver.
For example:
/* Only DWMAC core version 5.20 onwards supports HW descriptor prefetch.
*/
if (priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
This will match your 25GMAC cores and the XGMAC cores because they have
a Synopsys IP version number less than 0x52. What saves us there is
that dche is only read by dwmac4_dma_init(), used by dwmac4_dma_ops and
dwmac410_dma_ops. These are all used by hwif entries that require
priv->plat->core_type to be DWMAC_CORE_GMAC4. Thus, I'm changing this
one to:
/* Only DWMAC4 core version 5.20 onwards support HW descriptor prefetch.
*/
if (priv->plat->core_type != DWMAC_CORE_GMAC4 ||
priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
although I'm wondering if that should really be == && to avoid writing
to it for non-GMAC4 cores (it really doesn't matter.)
Then there this:
case HWTSTAMP_FILTER_PTP_V2_EVENT:
/* PTP v2/802.AS1 any layer, any kind of event packet */
config->rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
if (priv->snpsver < DWMAC_CORE_4_10)
ts_event_en = PTP_TCR_TSEVNTENA;
Is PTP_TCR_TSEVNTENA needed for this PTP filter type for XGMAC and
25GMAC cores - because they'll get it because they have snpsver
smaller than 0x41.
Similar here:
if (priv->plat->rx_coe) {
priv->hw->rx_csum = priv->plat->rx_coe;
dev_info(priv->device, "RX Checksum Offload Engine supported\n")+;
if (priv->snpsver < DWMAC_CORE_4_00)
dev_info(priv->device, "COE Type %d\n", priv->hw->rx_csu+m);
}
In stmmac_ethtool.c, stmmac_mac_debug() won't be called for XGMAC or
25GMAC cores, because:
if (priv->snpsver >= DWMAC_CORE_3_50)
stmmac_mac_debug(priv, priv->ioaddr,
(void *)&priv->xstats,
rx_queues_count, tx_queues_count);
snpsver (synopsys_id) will be smaller than 0x35. Is this correct?
The good news is that stmmac_mdio.c at gates all its checks on the
Synopsys IP version against the core type.
I'll post my RFC patches tidying up some of the version mess in the
next day or so.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 5/6] perf arm_spe: Decode Arm N1 IMPDEF events
From: Leo Yan @ 2026-04-07 15:44 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-5-55d3ef997c48@linaro.org>
On Tue, Apr 07, 2026 at 03:05:19PM +0100, James Clark wrote:
> From the TRM [1], N1 has one IMPDEF event which isn't covered by the
> common list. Add a framework so that more cores can be added in the
> future and that the N1 IMPDEF event can be decoded. Also increase the
> size of the buffer because we're adding more strings and if it gets
> truncated it falls back to a hex dump only.
>
> [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
> Suggested-by: Al Grant <al.grant@arm.com>
> Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* [PATCH mt76] wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S
From: Zenm Chen @ 2026-04-07 15:44 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang, matthias.bgg,
angelogioacchino.delregno, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: zenmchen, stable
Add the ID 056e:400a to the table to support an additional MT7612U
adapter: ELECOM WDC-867SU3S.
Compile tested only.
Cc: stable@vger.kernel.org # 5.10.x
Signed-off-by: Zenm Chen <zenmchen@gmail.com>
---
This ID was found from [1] and adding it to the device table should be
enough to make it work. Hardware probes at [2] can prove its existence.
[1] https://bushowhige.blogspot.com/2019/08/ubuntu-1804-mediatek-usb-wi-fi.html
[2] https://linux-hardware.org/?id=usb:056e-400a
---
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
index 01cb3b283..459c4044f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
@@ -16,6 +16,7 @@ static const struct usb_device_id mt76x2u_device_table[] = {
{ USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USBAC1200 - Alfa AWUS036ACM */
{ USB_DEVICE(0x057c, 0x8503) }, /* Avm FRITZ!WLAN AC860 */
{ USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
+ { USB_DEVICE(0x056e, 0x400a) }, /* ELECOM WDC-867SU3S */
{ USB_DEVICE(0x0e8d, 0x7632) }, /* HC-M7662BU1 */
{ USB_DEVICE(0x0471, 0x2126) }, /* LiteOn WN4516R module, nonstandard USB connector */
{ USB_DEVICE(0x0471, 0x7600) }, /* LiteOn WN4519R module, nonstandard USB connector */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 6/6] perf arm_spe: Print remaining IMPDEF event numbers
From: Leo Yan @ 2026-04-07 15:46 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-6-55d3ef997c48@linaro.org>
On Tue, Apr 07, 2026 at 03:05:20PM +0100, James Clark wrote:
> Any IMPDEF events not printed out from a known core's IMPDEF list or for
> a completely unknown core will still not be shown to the user. Fix this
> by printing the remaining bits as comma separated raw numbers, e.g.
> "IMPDEF:1,2,3,4".
>
> Suggested-by: Al Grant <al.grant@arm.com>
> Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: arm: cpus: Add Apple M3 CPU core compatibles
From: Rob Herring @ 2026-04-07 16:06 UTC (permalink / raw)
To: Janne Grunau
Cc: Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Sven Peter,
Neal Gompa, Wim Van Sebroeck, Guenter Roeck, Linus Walleij,
Mark Kettenis, Andi Shyti, Uwe Kleine-König,
Sasha Finkelstein, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-watchdog, linux-gpio, linux-i2c,
linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-1-5842e1e393a8@jannau.net>
On Fri, Mar 20, 2026 at 01:23:19PM +0100, Janne Grunau wrote:
> Add "apple,everest" compatible for the M3 performance core and
> "apple,sawtooth" for the M3 efficiency CPU core. These CPU cores are
> found on Apple Silicon SoCs M3 and M3 Pro, Max and Ultra.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH 2/9] dt-bindings: arm: apple: apple,pmgr: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:07 UTC (permalink / raw)
To: Janne Grunau
Cc: Linus Walleij, linux-arm-kernel, devicetree, asahi,
Wim Van Sebroeck, linux-pwm, Lorenzo Pieralisi, Guenter Roeck,
linux-kernel, linux-i2c, linux-gpio, Andi Shyti, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, Sven Peter, Neal Gompa,
Krzysztof Kozlowski, linux-watchdog, Conor Dooley
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-2-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:20 +0100, Janne Grunau wrote:
> The PMGR blocks on Apple silicon M3 SoCs (t8122) are compatible with the
> M1 and M2 predecessors. Add "apple,t8122-pmgr" as M3 specific
> compatible.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: imx8mm: imx8mp: Add DTOs for Data Modul i.MX8M Mini and Plus eDM SBC
From: Marek Vasut @ 2026-04-07 16:07 UTC (permalink / raw)
To: Frank Li
Cc: linux-arm-kernel, Conor Dooley, Fabio Estevam,
Krzysztof Kozlowski, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, devicetree, imx, linux-kernel
In-Reply-To: <adRhN_DDthCDHymn@lizhi-Precision-Tower-5810>
On 4/7/26 3:58 AM, Frank Li wrote:
> On Mon, Apr 06, 2026 at 11:58:45PM +0200, Marek Vasut wrote:
>> Add DT overlay for feature connector expansion module eDM-MOD-iMX8Mm-FIO1
>> providing additional UARTs, CAN, PWM Beeper, I2C, SPI and GPIO breakout.
>> This adapter can be optionally populated onto the eDM SBC.
>>
>> Add DT overlay for the DSI-to-HDMI adapter eDM-MOD-iMX8Mm-HDMI populated
>> with Lontium LT9611 bridge. This adapter can be optionally populated onto
>> the eDM SBC.
>>
>> Add DT overlay for the DSI-to-LVDS adapter eDM-MOD-iMX8Mm-LVDS populated
>> with Lontium LT9211 bridge. This adapter can be optionally populated onto
>> the eDM SBC. This adapter can be extended with multiple panels, currently
>> supported are the following:
>
> At least you can split to 3 patches to add these.
I did now, will send V3 patchset as 6 patches, but it won't help much
because most of the stuff is DSI-to-LVDS .
>> +#include "imx8mm-pinfunc.h"
>> +#include "imx8mm-data-modul-edm-sbc-overlay-edm-mod-imx8mm-fio1-audio.dtsi"
>> +
>> +&can_fio {
>> + interrupts-extended = <&gpio4 25 IRQ_TYPE_LEVEL_LOW>;
>
> Now, I have not good ways to unify this information for difference boards
> yet. It is quite common user case, let me think more.
It is a different interrupt line on these two boards.
>> +};
>> +
>> +&iomuxc {
>> + pinctrl_codec_mclk: codec-mclk_feature-grp {
>> + fsl,pins = <
>> + /* GPIO4_IO27 */
>> + MX8MM_IOMUXC_SAI2_MCLK_SAI5_MCLK 0x2
>> + >;
>> + };
>> +
>> + pinctrl_sai2: sai2_feature-grp {
>> + fsl,pins = <
>> + MX8MM_IOMUXC_SAI2_RXC_SAI2_RX_BCLK 0x90
>> + MX8MM_IOMUXC_SAI2_TXD0_SAI2_TX_DATA0 0x96
>> + MX8MM_IOMUXC_SAI2_RXD0_SAI2_RX_DATA0 0x90
>> + MX8MM_IOMUXC_SAI2_TXFS_SAI2_TX_SYNC 0x96
>> + >;
>> + };
>
> I think this part should be in main boards's dts file, there should have
> hardware plug header, which include these signals.
>
> If there are other added on boards, add-on dtso can resuse the label,
> pinctrl_sai2 and pinctrl_codec_mclk.
No, not really, the audio-board is a bit of an outlier so I would prefer
to keep the audio-board specific changes in the audio-board DTO instead
of polluting the base DT with its specifics.
>> +};
>> +
>> +&pinctrl_hog_feature {
>> + fsl,pins = <
>> + /* GPIO5_IO03 */
>> + MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 0x40000006
>> + /* GPIO5_IO04 */
>> + MX8MM_IOMUXC_SPDIF_RX_GPIO5_IO4 0x40000006
>> +
>> + /* CAN_INT# */
>> + MX8MM_IOMUXC_SAI2_TXC_GPIO4_IO25 0x40000090
>> + >;
>> +};
>> +
>> +&sai2 {
>> + assigned-clocks = <&clk IMX8MM_CLK_SAI2>;
>> + assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
>> + fsl,sai-bit-clock-swap;
>> +};
>> +
>> +&sgtl5000_fio {
>> + VDDA-supply = <&buck4_reg>;
>> + VDDD-supply = <&buck5_reg>;
>> + VDDIO-supply = <&buck4_reg>;
>
> buck4_reg can provide addtional label, such as porta_vdd ..., so needn't
> this sections.
I simply renamed the base DT regulator names to buckN_reg and ldoN_reg
for both MX8MM and MX8MP eDM SBC , no need for additional labels .
>> +};
>> +
>> +&spba2 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + sai5clk: clock-controller@30050000 { /* SAI5 */
>> + compatible = "fsl,imx8mm-sai-clock", "fsl,imx8mq-sai-clock";
>> + reg = <0x30050000 0x10000>;
>> + #clock-cells = <1>;
>
> Not sure why need overwrite these informaiton here, suppose it should be
> the same for Soc.
I don't quite understand this comment, I am adding a node separate from
the sai5 node, so I won't end up pulling in unrelated properties for the
"fsl,imx8mm-sai-clock" (which is not "fsl,imx8mm-sai").
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: watchdog: apple,wdt: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:07 UTC (permalink / raw)
To: Janne Grunau
Cc: Neal Gompa, linux-i2c, Linus Walleij, Uwe Kleine-König,
Mark Kettenis, Krzysztof Kozlowski, linux-kernel, Guenter Roeck,
devicetree, Sasha Finkelstein, Wim Van Sebroeck, linux-pwm,
linux-arm-kernel, Sven Peter, asahi, Conor Dooley, linux-gpio,
linux-watchdog, Andi Shyti, Lorenzo Pieralisi
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-4-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:22 +0100, Janne Grunau wrote:
> The watchdog on the Apple silicon t8122 (M3) SoC is compatible with the
> existing driver. Add "apple,t8122-wdt" as SoC specific compatible under
> "apple,t8103-wdt" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/watchdog/apple,wdt.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: power: apple,pmgr-pwrstate: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: devicetree, linux-arm-kernel, linux-i2c, Conor Dooley, Sven Peter,
Wim Van Sebroeck, Uwe Kleine-König, Mark Kettenis,
Andi Shyti, linux-kernel, Krzysztof Kozlowski, Neal Gompa,
Sasha Finkelstein, linux-gpio, linux-pwm, Guenter Roeck,
Linus Walleij, asahi, linux-watchdog, Lorenzo Pieralisi
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-3-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:21 +0100, Janne Grunau wrote:
> The device power state management of the PMGR blocks on Apple's t8122
> SoC (M3) is compatible with the existing driver.
> Add "apple,t8122-pmgr-pwrstate" as SoC specific compatible under the
> existing "apple,t8103-pmgr-pwrstate" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: i2c: apple,i2c: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: Andi Shyti, Wim Van Sebroeck, Sven Peter, linux-watchdog,
linux-kernel, Sasha Finkelstein, devicetree, Neal Gompa, asahi,
Mark Kettenis, linux-pwm, Guenter Roeck, Krzysztof Kozlowski,
linux-arm-kernel, linux-i2c, linux-gpio, Uwe Kleine-König,
Conor Dooley, Lorenzo Pieralisi, Linus Walleij
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-6-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:24 +0100, Janne Grunau wrote:
> The i2c block on the Apple silicon t8122 (M3) SoC is compatible with the
> existing driver. Add "apple,t8122-i2c" as SoC specific compatible under
> "apple,t8103-i2c" used by the deriver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/i2c/apple,i2c.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: Uwe Kleine-König, Lorenzo Pieralisi, Sven Peter, devicetree,
Andi Shyti, asahi, Guenter Roeck, Krzysztof Kozlowski,
Wim Van Sebroeck, linux-i2c, linux-pwm, Mark Kettenis,
linux-kernel, Linus Walleij, linux-watchdog, Sasha Finkelstein,
Conor Dooley, linux-gpio, Neal Gompa, linux-arm-kernel
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-5-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:23 +0100, Janne Grunau wrote:
> The pin controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-pinctrl" as SoC specific
> compatible under "apple,t8103-pinctrl" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 7/9] dt-bindings: pwm: apple,s5l-fpwm: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:09 UTC (permalink / raw)
To: Janne Grunau
Cc: Neal Gompa, linux-arm-kernel, linux-gpio, linux-i2c,
Uwe Kleine-König, Wim Van Sebroeck, linux-watchdog,
devicetree, Guenter Roeck, Krzysztof Kozlowski, Sven Peter,
Sasha Finkelstein, Lorenzo Pieralisi, Andi Shyti, Mark Kettenis,
Linus Walleij, linux-pwm, linux-kernel, asahi, Conor Dooley
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-7-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:25 +0100, Janne Grunau wrote:
> The PWM controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-fpwm" as SoC specific
> compatible under "apple,s5l-fpwm" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 8/9] dt-bindings: arm: apple: Add M3 based devices
From: Rob Herring (Arm) @ 2026-04-07 16:10 UTC (permalink / raw)
To: Janne Grunau
Cc: devicetree, Lorenzo Pieralisi, Wim Van Sebroeck, linux-watchdog,
linux-arm-kernel, linux-kernel, asahi, Guenter Roeck, Neal Gompa,
Andi Shyti, linux-gpio, Conor Dooley, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, Sven Peter,
Linus Walleij, Krzysztof Kozlowski, linux-i2c, linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-8-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:26 +0100, Janne Grunau wrote:
> The Apple devices with the t8122 SoC (M3) are very similar to their M1
> and M2 predecessors.
> Only the 13-inch Macbook Pro is replaced by a 14-inch version based on
> the design of the 14-inch Macbook Pro with (M1/M2 Pro/Max). The Mac mini
> was not offered with M3.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/arm/apple.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: pinctrl: sun55i-a523: increase IRQ bank number
From: Rob Herring (Arm) @ 2026-04-07 16:14 UTC (permalink / raw)
To: Andre Przywara
Cc: linux-sunxi, Chen-Yu Tsai, linux-arm-kernel, Linus Walleij,
Krzysztof Kozlowski, Michal Piekos, linux-gpio, linux-kernel,
Samuel Holland, Conor Dooley, devicetree, Jernej Skrabec
In-Reply-To: <20260323110151.2352832-4-andre.przywara@arm.com>
On Mon, 23 Mar 2026 12:01:49 +0100, Andre Przywara wrote:
> The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
> instance, but it skips the first bank (PortA), so their index goes from
> 1 to 10. The same is actually true for the IRQ banks: there are registers
> for 11 banks, though the first bank is not implemented (RAZ/WI).
> In contrast to previous SoCs, the count of the IRQ banks starts with this
> first unimplemented bank, so we need to provide an interrupt for it.
> And indeed the A523 user manual lists an interrupt number for PortA, so we
> need to increase the maximum number of interrupts per pin controller to 11,
> to be able to assign the correct interrupt number for each bank.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 2/3] dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
From: Conor Dooley @ 2026-04-07 16:20 UTC (permalink / raw)
To: florin.leotescu
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel,
daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-3-florin.leotescu@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Thu, Apr 02, 2026 at 03:25:13PM +0300, florin.leotescu@oss.nxp.com wrote:
> From: Florin Leotescu <florin.leotescu@nxp.com>
>
> The EMC2305 fan controller supports multiple independent PWM fan
> outputs. Some systems require fans to enter a defined safe state
> during system shutdown or reboot handoff, until firmware or the next
> boot stage reconfigures the controller.
>
> Add an optional "fan-shutdown-percent" property to fan child nodes
> allowing the PWM duty cycle applied during shutdown to be configured
> per fan output.
>
> Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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