* Re: [PATCH v4 2/5] arm_mpam: resctrl: Pre-allocate assignable monitors
From: Fenghua Yu @ 2026-07-03 5:30 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, zengheng4, x86
In-Reply-To: <20260520212458.1797221-3-ben.horgan@arm.com>
Hi, Ben,
On 5/20/26 14:24, Ben Horgan wrote:
> MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory
> bandwidth monitors assignable. Rather than supporting the 'default'
> mbm_assign_mode always use 'mbm_event' mode even if there are sufficient
> memory bandwidth monitors. The per monitor event configuration is only
> provided by resctrl when in 'mbm_event' mode and so only allowing
> 'mbm_event' mode will make it easier to support per-monitor event
> configuration for MPAM. For the moment, the only event supported is
> mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode'
> file will still show 'default' when there is no support for memory
> bandwidth monitoring.
>
> The monitors need to be allocated from the driver, and mapped to whichever
> control/monitor group resctrl wants to use them with.
>
> Add a second array to hold the monitor values indexed by resctrl's cntr_id.
>
> When CDP is in use, two monitors are needed so the available number of
> counters halves. Platforms with one monitor will have zero monitors when
> CDP is in use.
>
> Co-developed-by: James Morse <james.morse@arm.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
Please check the following nit.
> ---
> Changes since rfc v1:
> abmc enabled even if enough counters
> Helpers from dropped free running commits
> carry on with zero counters if using cdp
> set config bits
> use kmalloc_objs
> drop tags for rework
> Configure mbm_cntr_configurable, mbm_cntr_assign_fixed
>
> Changes since rfc v2:
> Don't set mon->assigned_counters to an error pointer
> Fix mpam_resctrl_teardown_mon()
> Remove free running check
> Separate cleanup allocations, e.g. __free(), from the rest
> Restrict scope on err in mpam_resctrl_monitor_init()
>
> Changes since v3:
> Correct NULL check in mpam_resctrl_teardown_mon() (Shaopeng)
> variable allocation ordering in mpam_resctrl_pick_domain_id() (Shaopeng)
> Move mon.* assignments from mpam_resctrl_monitor_sync_abmc_vals()
> to mpam_resctrl_monitor_init_abmc() counters (Sashiko)
> use kvmalloc_obj() for allocations that may be big on some
> platforms (Sashiko)
> ---
> drivers/resctrl/mpam_internal.h | 6 +-
> drivers/resctrl/mpam_resctrl.c | 139 +++++++++++++++++++++++++++++++-
> 2 files changed, 141 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
> index 1914aefdcba9..7a166b395b5a 100644
> --- a/drivers/resctrl/mpam_internal.h
> +++ b/drivers/resctrl/mpam_internal.h
> @@ -411,7 +411,11 @@ struct mpam_resctrl_res {
> struct mpam_resctrl_mon {
> struct mpam_class *class;
>
> - /* per-class data that resctrl needs will live here */
> + /* Array of allocated MBWU monitors, indexed by (closid, rmid). */
> + int *mbwu_idx_to_mon;
> +
> + /* Array of assigned MBWU monitors, indexed by idx argument. */
Nit:
"idx argument" is unclear and confusing. The idx is actually cntr_id
coming from resctrl.
Is it better s/index by idx argument/indexed by resctrl's cntr_id/?
You mentioned "indexed by resctrl's cntr_id" in the commit message
already. I think it's clearer than simple "idx argument".
> + int *assigned_counters;
> };
>
[SNIP]
Thanks.
-Fenghua
^ permalink raw reply
* [PATCH v3] cpufreq: apple-soc: Fix OPP table cleanup
From: Haoxiang Li @ 2026-07-03 6:20 UTC (permalink / raw)
To: sven, j, neal, rafael, viresh.kumar, marcan, maz
Cc: asahi, linux-arm-kernel, linux-pm, linux-kernel, Haoxiang Li,
stable
apple_soc_cpufreq_init() adds OPP tables from firmware, but
some failure paths do not remove them. The driver also uses
dev_pm_opp_remove_all_dynamic(), which is not the right cleanup
helper for OPP tables loaded from firmware.
Use the cpumask OPP helper after the policy CPU mask has been
populated. Pair it with the matching cpumask remove helper on
failure paths and in apple_soc_cpufreq_exit(). This also removes
the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask
helper loads the DT OPP tables for all CPUs in the policy.
Fixes: 6286bbb40576 ("cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
Changes in v2:
- Remove unnecessary cleanup calls.
- Remove OPP table from apple_soc_cpufreq_exit(). Thanks, Viresh!
Changes in v3:
- Add Fixes and Cc stable tags.
- Use cpumask OPP helpers.
- Reorder init and failure cleanup. Thanks, Viresh!
---
drivers/cpufreq/apple-soc-cpufreq.c | 36 +++++++++++------------------
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c
index 638e5bf72185..3f64f266e695 100644
--- a/drivers/cpufreq/apple-soc-cpufreq.c
+++ b/drivers/cpufreq/apple-soc-cpufreq.c
@@ -249,21 +249,19 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
return -ENODEV;
}
- ret = dev_pm_opp_of_add_table(cpu_dev);
- if (ret < 0) {
- dev_err(cpu_dev, "%s: failed to add OPP table: %d\n", __func__, ret);
- return ret;
- }
+ priv = kzalloc_obj(*priv);
+ if (!priv)
+ return -ENOMEM;
ret = apple_soc_cpufreq_find_cluster(policy, ®_base, &info);
if (ret) {
dev_err(cpu_dev, "%s: failed to get cluster info: %d\n", __func__, ret);
- return ret;
+ goto out_free_priv;
}
- ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
- if (ret) {
- dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n", __func__, ret);
+ ret = dev_pm_opp_of_cpumask_add_table(policy->cpus);
+ if (ret < 0) {
+ dev_err(cpu_dev, "%s: failed to add OPP table: %d\n", __func__, ret);
goto out_iounmap;
}
@@ -271,19 +269,13 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
if (ret <= 0) {
dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
ret = -EPROBE_DEFER;
- goto out_free_opp;
- }
-
- priv = kzalloc_obj(*priv);
- if (!priv) {
- ret = -ENOMEM;
- goto out_free_opp;
+ goto out_free_table;
}
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
if (ret) {
dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
- goto out_free_priv;
+ goto out_free_table;
}
/* Get OPP levels (p-state indexes) and stash them in driver_data */
@@ -318,12 +310,12 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
out_free_cpufreq_table:
dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
-out_free_priv:
- kfree(priv);
-out_free_opp:
- dev_pm_opp_remove_all_dynamic(cpu_dev);
+out_free_table:
+ dev_pm_opp_of_cpumask_remove_table(policy->cpus);
out_iounmap:
iounmap(reg_base);
+out_free_priv:
+ kfree(priv);
return ret;
}
@@ -332,7 +324,7 @@ static void apple_soc_cpufreq_exit(struct cpufreq_policy *policy)
struct apple_cpu_priv *priv = policy->driver_data;
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
- dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
+ dev_pm_opp_of_cpumask_remove_table(policy->cpus);
iounmap(priv->reg_base);
kfree(priv);
}
--
2.25.1
^ permalink raw reply related
* RE: [PATCH v1 3/5] iommufd/selftest: Convert cache invalidation mocks to the core array loop
From: Tian, Kevin @ 2026-07-03 6:22 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Jason Gunthorpe, Lu Baolu
Cc: Robin Murphy, joro@8bytes.org, David Woodhouse,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <0b590a04fe2d38d696d0e31e37d8afdb1b6725f2.1782767398.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
>
> + /*
> + * The core re-invokes this op for the remaining requests, so handle
> one
> + * request per call. A zero-length array only probes the type,
> validated
> + * above.
> + */
> + if (!array->entry_num)
> + goto out;
>
it's clearer to directly return 0 here.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
^ permalink raw reply
* RE: [PATCH v1 1/5] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands
From: Tian, Kevin @ 2026-07-03 6:20 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Jason Gunthorpe, Lu Baolu
Cc: Robin Murphy, joro@8bytes.org, David Woodhouse,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <eb89a1c564956d9a2ba1d56bd76d57defac205aa.1782767398.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
>
> The arm_vsmmu_cache_invalidate() op hands a guest's invalidation
> commands
> to the trusted main command queue after enforcing only the VMID or the
> SID,
> and passes the rest of the command through to the queue unchanged.
>
> That lets a guest set bits the host never meant to forward, in two ways. A
> bit can take the command out of the guest's own scope: the ATC_INV Global
> bit, for one, makes the SMMU ignore the SID and invalidate the ATC of every
> device, not just the guest's. A reserved or undefined bit instead makes the
> command malformed; per the Arm SMMUv3 specification, in its section 4.1.3
> "Command errors", a CERROR_ILL is raised, among other cases, when:
>
> A valid command opcode is used and a Reserved or undefined field is
> optionally detected as non-zero, which results in the command being
> treated as malformed.
>
> Restrict each opcode to the fields that the driver supports and reject the
> command with -EIO if it sets any other bit, before the command reaches the
> queue. This keeps a guest scoped to its own devices and stops the host from
> forwarding any bit whose meaning it does not control.
>
> Some fields and whole opcodes are legal only on an SMMU that implements
> the
> matching feature, so accept them conditionally. The NUM, SCALE and TG
> range
> fields need FEAT_RANGE_INV. The ATC_INV opcode needs FEAT_ATS. Per the
> same
> specification's section 4.5 "ATS and PRI", CMD_ATC_INV is ILLEGAL when:
>
> SMMU_IDR0.ATS == 0 and this command is issued on a Non-secure or
> Secure
> Command queue.
>
> The SSV and SSID substream fields require a non-zero ssid_bits, so without
> substream support setting them is not illegal but CONSTRAINED
> UNPREDICTABLE,
> which a guest should not be able to provoke.
>
> Fixes: d68beb276ba2 ("iommu/arm-smmu-v3: Support
> IOMMU_HWPT_INVALIDATE using a VIOMMU object")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> + case CMDQ_OP_ATC_INV:
> + /*
> + * Exclude the Global bit: it makes the SMMU ignore the SID
> and
> + * invalidate the ATC of every device, not just the guest's.
> + */
I suppose the Global bit in vcmdq is guaranteed by HW to be contained within
the vcmdq, then the SMMU will convert it into multiple INV cmds sent to
devices associated with the vcmdq?
> + allowed[0] |= CMDQ_ATC_0_SID;
> + allowed[1] |= CMDQ_ATC_1_SIZE |
> CMDQ_ATC_1_ADDR_MASK;
> + /* SSV/SSID require substream support */
> + if (vsmmu->smmu->ssid_bits)
> + allowed[0] |= CMDQ_0_SSV | CMDQ_ATC_0_SSID;
> + break;
the latter check of ARM_SMMU_FEAT_ATS could be moved here before
setting any allowed bits for ATC_INV.
^ permalink raw reply
* RE: [PATCH v1 2/5] iommufd: Iterate the cache invalidation array in the core
From: Tian, Kevin @ 2026-07-03 6:21 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Jason Gunthorpe, Lu Baolu
Cc: Robin Murphy, joro@8bytes.org, David Woodhouse,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <dc0c92e0688db085e12e0b6931c49384489da887.1782767398.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
>
> @@ -535,8 +535,15 @@ int iommufd_hwpt_invalidate(struct
> iommufd_ucmd *ucmd)
> rc = -EOPNOTSUPP;
> goto out_put_pt;
> }
> - rc = hwpt->domain->ops->cache_invalidate_user(hwpt-
> >domain,
> - &data_array);
> + do {
> + rc = hwpt->domain->ops->cache_invalidate_user(
> + hwpt->domain, &data_array);
> +
> + done_num += data_array.entry_num;
> + data_array.uptr +=
> + data_array.entry_num * cmd->entry_len;
> + data_array.entry_num = cmd->entry_num -
> done_num;
> + } while (!rc && done_num != cmd->entry_num);
> } else if (pt_obj->type == IOMMUFD_OBJ_VIOMMU) {
> struct iommufd_viommu *viommu =
> container_of(pt_obj, struct iommufd_viommu, obj);
> @@ -545,14 +552,19 @@ int iommufd_hwpt_invalidate(struct
> iommufd_ucmd *ucmd)
> rc = -EOPNOTSUPP;
> goto out_put_pt;
> }
> - rc = viommu->ops->cache_invalidate(viommu, &data_array);
> + do {
> + rc = viommu->ops->cache_invalidate(viommu,
> &data_array);
> +
> + done_num += data_array.entry_num;
> + data_array.uptr +=
> + data_array.entry_num * cmd->entry_len;
> + data_array.entry_num = cmd->entry_num -
> done_num;
> + } while (!rc && done_num != cmd->entry_num);
> } else {
> rc = -EINVAL;
> goto out_put_pt;
> }
>
the two loops above can be consolidated into one after the ops is
selected.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
^ permalink raw reply
* Re: [PATCH 05/42] drm/mediatek: Rename all display component type to have DISP_ prefix
From: CK Hu (胡俊光) @ 2026-07-03 6:25 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, chunkuang.hu@kernel.org
Cc: robh@kernel.org, tzimmermann@suse.de, simona@ffwll.ch,
mripard@kernel.org, kernel@collabora.com,
linux-mediatek@lists.infradead.org,
maarten.lankhorst@linux.intel.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
krzk+dt@kernel.org, p.zabel@pengutronix.de, airlied@gmail.com,
Justin Yeh (葉英茂), matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org,
Jason-JH Lin (林睿祥)
In-Reply-To: <20260701122057.19648-6-angelogioacchino.delregno@collabora.com>
On Wed, 2026-07-01 at 14:20 +0200, AngeloGioacchino Del Regno wrote:
> The mtk_ddp_comp_type enumeration will end up containing both the
> Display Controller and Media Data Path Controller components: this
> is because those can be interconnected together (as in, using MDP
> components in Display Controller paths is possible!) and because
> both MMSYS and MuteX are managing both of those in practically the
> same way.
>
> Rename all of the Display Controller related HW components in the
> list to always have a "DISP_" prefix.
> This includes components that are in the MDP Controller instead,
> and the strategy here is for some of those to also have the same
> DISP_ prefix, so that:
> - Display Controller specific components have a DISP_ prefix
> - Example: MTK_DISP_(NAME)
> - MDP Controller components that can be interconnected to the
> Display Controller will have both DISP_ and MDP_ prefixes
> - Example: MTK_DISP_MDP_(NAME)
> - MDP Controller components that are exclusive to MDP and can
> not be interconnected with Display Controller will only have
> an MDP_ prefix but not a DISP_ prefix
> - Example: MTK_MDP_(NAME).
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
^ permalink raw reply
* Re: [PATCH v6 01/12] dt-bindings: soc: zte: Add zx297520v3 top clock and reset bindings
From: Krzysztof Kozlowski @ 2026-07-03 6:26 UTC (permalink / raw)
To: Stefan Dösinger, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260702-zx29clk-v6-1-377b704f80c4@gmail.com>
On 02/07/2026 22:27, Stefan Dösinger wrote:
> These SoCs have 3 clock and reset controllers: Top, Matrix and LSP. The
> separation of concerns between Top and Matrix and the interface between
> them is poorly defined in the hardware, so the bindings list all
> potential PLL clocks that might be passed between them.
>
> Generally every device has two clocks (one work clock, and one that
> connects it to the bus, I call it PCLK), two reset bits (I don't know
> what the difference is - sometimes asserting one is enough to reset the
> device, sometimes both need to be asserted). PCLK and WCLK are
> controlled by individual gates. Some devices have a mux and/or a
> divider for their work clock. Some devices, like the GPIO controller,
> only have reset bits and no clocks.
>
> The top clock controller is fed by a 26mhz external oscillator and has 4
> PLLs to generate other clock rates. ZTE's kernel mostly relies on the
> boot ROM to set up PLLs, but one LTE-Related PLL is not configured
> on some boards. Therefore my driver contains code to program PLLs. It
> produces identical settings as the boot ROM for the pre-programmed
> frequencies.
>
> Not all clocks will have an explicit user in the end. I am defining a
> lot of them simply to shut them off. The boot loader sets up a few of
> the proprietary timers, which will send regular IRQs (although the
> kernel of course doesn't need to listen to them). I don't plan to add a
> driver for the proprietary timer as I see no use for them - the ARM arch
> timer works just fine. I will add a driver for the very similar
> proprietary watchdog though.
>
> The clock list in this patch is pretty complete but not exhaustive.
> There are other bits that are enabled, but I couldn't deduce what they
> are controlling by trial and error. Some of them seem to do nothing.
> Others cause an instant hang of the board when disabled. It is quite
> likely that a handful more clocks will be added in the future, but not a
> large number.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
> Changes v5->v6:
> Set value for syscon-reboot example (Sashiko). It was my intention to
> set only the lowest bit, and I think Sashiko is right that without
> 'value' being set, all other bits are actively set to 0. It shouldn't
> matter given my understanding of the hardware (afaics all other bits are
> ignored), but actively clearing bits was not my intention.
>
> I haven't changed the name match for "syscon-reboot". I see plenty of
> examples of hardcoding this string as opposed to having a regex for
> syscon-reboot@12345678 in other bindings.
>
> Changes v4->v5:
>
> Rename from zte,zx297520v3-topclk to zte,zx297520v3-topcrm and move to
> soc/zte
> Fix path in MAINTAINERS
> Add syscon-reboot node to the binding
> Give the USB and HSIC PHY resets their own reset control
> ---
> .../bindings/soc/zte/zte,zx297520v3-topcrm.yaml | 86 +++++++++++++++++++
> MAINTAINERS | 3 +
> include/dt-bindings/clock/zte,zx297520v3-clk.h | 97 ++++++++++++++++++++++
> include/dt-bindings/reset/zte,zx297520v3-reset.h | 32 +++++++
> 4 files changed, 218 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/zte/zte,zx297520v3-topcrm.yaml b/Documentation/devicetree/bindings/soc/zte/zte,zx297520v3-topcrm.yaml
> new file mode 100644
> index 000000000000..5a5d97120056
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/zte/zte,zx297520v3-topcrm.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/zte/zte,zx297520v3-topcrm.yaml#
Also, this cannot be placed in soc. Clock and reset controllers DO NOT
go to the soc directory. Place in it clocks.
A nit, subject: drop second/last, redundant "bindings". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] cpufreq: apple-soc: Fix OPP table cleanup
From: Viresh Kumar @ 2026-07-03 6:27 UTC (permalink / raw)
To: Haoxiang Li
Cc: sven, j, neal, rafael, marcan, maz, asahi, linux-arm-kernel,
linux-pm, linux-kernel, stable
In-Reply-To: <20260703062049.1459175-1-haoxiang_li2024@163.com>
On 03-07-26, 14:20, Haoxiang Li wrote:
> apple_soc_cpufreq_init() adds OPP tables from firmware, but
> some failure paths do not remove them. The driver also uses
> dev_pm_opp_remove_all_dynamic(), which is not the right cleanup
> helper for OPP tables loaded from firmware.
>
> Use the cpumask OPP helper after the policy CPU mask has been
> populated. Pair it with the matching cpumask remove helper on
> failure paths and in apple_soc_cpufreq_exit(). This also removes
> the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask
> helper loads the DT OPP tables for all CPUs in the policy.
>
> Fixes: 6286bbb40576 ("cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> Changes in v2:
> - Remove unnecessary cleanup calls.
> - Remove OPP table from apple_soc_cpufreq_exit(). Thanks, Viresh!
> Changes in v3:
> - Add Fixes and Cc stable tags.
> - Use cpumask OPP helpers.
> - Reorder init and failure cleanup. Thanks, Viresh!
> ---
> drivers/cpufreq/apple-soc-cpufreq.c | 36 +++++++++++------------------
> 1 file changed, 14 insertions(+), 22 deletions(-)
Applied. Thanks.
--
viresh
^ permalink raw reply
* Re: [PATCH v3] virt: arm-cca-guest: use migrate_disable() for attestation token requests
From: Kohei Enju @ 2026-07-03 6:28 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: Catalin Marinas, Will Deacon, Suzuki K Poulose, Sami Mujawar,
Steven Price, Gavin Shan
In-Reply-To: <20260612111007.49434-1-enju.kohei@fujitsu.com>
Hi all,
Just a gentle ping on this v3 patch.
This v3 switches the implementation to use migrate_disable() and calls
the RSI attestation token operations directly, following the feedback
on the previous versions.
Any comments would be appreciated.
Thanks,
Kohei
On 06/12 20:09, Kohei Enju wrote:
> The RSI attestation token init and continue calls must be issued from
> the same CPU. arm_cca_report_new() currently snapshots the CPU number
> and uses smp_call_function_single() to issue those calls on that CPU.
>
> With CONFIG_DEBUG_PREEMPT=y, the smp_processor_id() call used for the
> snapshot triggers a debug splat [0] because it runs in preemptible
> context. The snapshot does not pin the task to that CPU; it is only used
> to choose the target CPU for smp_call_function_single(), which can fail
> if that CPU is no longer available.
>
> Use migrate_disable() and issue the token init and continue operations
> directly, without the smp_call_function_single() callbacks. This keeps
> the token request sequence on the same CPU while preserving a sleepable
> context for the GFP_KERNEL allocations needed after the init call.
>
> [0]
> BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/264
> caller is debug_smp_processor_id+0x20/0x30
> CPU: 0 UID: 0 PID: 264 Comm: cca-workload-at Not tainted 7.1.0-rc1-00044-g55542ab273f2 #80 PREEMPT(lazy)
> Hardware name: linux,dummy-virt (DT)
> Call trace:
> [...]
> check_preemption_disabled+0xd8/0xf8
> debug_smp_processor_id+0x20/0x30
> arm_cca_report_new+0x48/0x278
> tsm_report_read+0x154/0x1f8
> tsm_report_outblob_read+0x20/0x38
> configfs_bin_read_iter+0x118/0x208
> vfs_read+0x220/0x318
> [...]
>
> Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
> Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
> ---
> Changes:
> v3:
> - Switch to migrate_disable() and call RSI directly, removing
> smp_call_function_single() (Will, Suzuki)
> - Remove arm_cca_attestation_init() helper and unused fields from
> arm_cca_token_info
> - Drop Reviewed-by tags since the approach changed from v2
> v2: https://lore.kernel.org/linux-arm-kernel/20260519101217.155740-1-enju.kohei@fujitsu.com/
> - Add comment about why this path doesn't use migrate_disable()
> v1: https://lore.kernel.org/linux-arm-kernel/20260518033157.1865498-1-enju.kohei@fujitsu.com/
> ---
> .../virt/coco/arm-cca-guest/arm-cca-guest.c | 97 +++++++------------
> 1 file changed, 36 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> index 66d00b6ceb78..a38df08da6fa 100644
> --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> @@ -16,54 +16,38 @@
>
> /**
> * struct arm_cca_token_info - a descriptor for the token buffer.
> - * @challenge: Pointer to the challenge data
> - * @challenge_size: Size of the challenge data
> * @granule: PA of the granule to which the token will be written
> * @offset: Offset within granule to start of buffer in bytes
> - * @result: result of rsi_attestation_token_continue operation
> */
> struct arm_cca_token_info {
> - void *challenge;
> - unsigned long challenge_size;
> phys_addr_t granule;
> unsigned long offset;
> - unsigned long result;
> };
>
> -static void arm_cca_attestation_init(void *param)
> -{
> - struct arm_cca_token_info *info;
> -
> - info = (struct arm_cca_token_info *)param;
> -
> - info->result = rsi_attestation_token_init(info->challenge,
> - info->challenge_size);
> -}
> -
> /**
> * arm_cca_attestation_continue - Retrieve the attestation token data.
> *
> - * @param: pointer to the arm_cca_token_info
> + * @info: pointer to the arm_cca_token_info
> *
> * Attestation token generation is a long running operation and therefore
> * the token data may not be retrieved in a single call. Moreover, the
> * token retrieval operation must be requested on the same CPU on which the
> * attestation token generation was initialised.
> - * This helper function is therefore scheduled on the same CPU multiple
> + * This helper function must therefore be executed on the same CPU multiple
> * times until the entire token data is retrieved.
> */
> -static void arm_cca_attestation_continue(void *param)
> +static unsigned long
> +arm_cca_attestation_continue(struct arm_cca_token_info *info)
> {
> + unsigned long ret;
> unsigned long len;
> unsigned long size;
> - struct arm_cca_token_info *info;
> -
> - info = (struct arm_cca_token_info *)param;
>
> size = RSI_GRANULE_SIZE - info->offset;
> - info->result = rsi_attestation_token_continue(info->granule,
> - info->offset, size, &len);
> + ret = rsi_attestation_token_continue(info->granule, info->offset, size,
> + &len);
> info->offset += len;
> + return ret;
> }
>
> /**
> @@ -74,8 +58,8 @@ static void arm_cca_attestation_continue(void *param)
> *
> * Initialise the attestation token generation using the challenge data
> * passed in the TSM descriptor. Allocate memory for the attestation token
> - * and schedule calls to retrieve the attestation token on the same CPU
> - * on which the attestation token generation was initialised.
> + * and retrieve the attestation token on the same CPU on which the
> + * attestation token generation was initialised.
> *
> * The challenge data must be at least 32 bytes and no more than 64 bytes. If
> * less than 64 bytes are provided it will be zero padded to 64 bytes.
> @@ -85,12 +69,11 @@ static void arm_cca_attestation_continue(void *param)
> * * %-EINVAL - A parameter was not valid.
> * * %-ENOMEM - Out of memory.
> * * %-EFAULT - Failed to get IPA for memory page(s).
> - * * A negative status code as returned by smp_call_function_single().
> */
> static int arm_cca_report_new(struct tsm_report *report, void *data)
> {
> - int ret;
> - int cpu;
> + int ret = 0;
> + unsigned long rsi_result;
> long max_size;
> unsigned long token_size = 0;
> struct arm_cca_token_info info;
> @@ -103,37 +86,33 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
>
> /*
> * The attestation token 'init' and 'continue' calls must be
> - * performed on the same CPU. smp_call_function_single() is used
> - * instead of simply calling get_cpu() because of the need to
> - * allocate outblob based on the returned value from the 'init'
> - * call and that cannot be done in an atomic context.
> + * performed on the same CPU, so disable CPU migration around
> + * those operations.
> */
> - cpu = smp_processor_id();
> + migrate_disable();
>
> - info.challenge = desc->inblob;
> - info.challenge_size = desc->inblob_len;
> -
> - ret = smp_call_function_single(cpu, arm_cca_attestation_init,
> - &info, true);
> - if (ret)
> - return ret;
> - max_size = info.result;
> -
> - if (max_size <= 0)
> - return -EINVAL;
> + max_size = rsi_attestation_token_init(desc->inblob, desc->inblob_len);
> + if (max_size <= 0) {
> + ret = -EINVAL;
> + goto exit_migrate_enable;
> + }
>
> /* Allocate outblob */
> token = kvzalloc(max_size, GFP_KERNEL);
> - if (!token)
> - return -ENOMEM;
> + if (!token) {
> + ret = -ENOMEM;
> + goto exit_migrate_enable;
> + }
>
> /*
> * Since the outblob may not be physically contiguous, use a page
> * to bounce the buffer from RMM.
> */
> buf = alloc_pages_exact(RSI_GRANULE_SIZE, GFP_KERNEL);
> - if (!buf)
> - return -ENOMEM;
> + if (!buf) {
> + ret = -ENOMEM;
> + goto exit_migrate_enable;
> + }
>
> /* Get the PA of the memory page(s) that were allocated */
> info.granule = (unsigned long)virt_to_phys(buf);
> @@ -144,21 +123,15 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> info.offset = 0;
> do {
> /*
> - * Schedule a call to retrieve a sub-granule chunk
> - * of data per loop iteration.
> + * Retrieve a sub-granule chunk of data per loop
> + * iteration.
> */
> - ret = smp_call_function_single(cpu,
> - arm_cca_attestation_continue,
> - (void *)&info, true);
> - if (ret != 0) {
> - token_size = 0;
> - goto exit_free_granule_page;
> - }
> - } while (info.result == RSI_INCOMPLETE &&
> + rsi_result = arm_cca_attestation_continue(&info);
> + } while (rsi_result == RSI_INCOMPLETE &&
> info.offset < RSI_GRANULE_SIZE);
>
> /* Break out in case of failure */
> - if (info.result != RSI_SUCCESS && info.result != RSI_INCOMPLETE) {
> + if (rsi_result != RSI_SUCCESS && rsi_result != RSI_INCOMPLETE) {
> ret = -ENXIO;
> token_size = 0;
> goto exit_free_granule_page;
> @@ -173,12 +146,14 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> break;
> memcpy(&token[token_size], buf, info.offset);
> token_size += info.offset;
> - } while (info.result == RSI_INCOMPLETE);
> + } while (rsi_result == RSI_INCOMPLETE);
>
> report->outblob = no_free_ptr(token);
> exit_free_granule_page:
> report->outblob_len = token_size;
> free_pages_exact(buf, RSI_GRANULE_SIZE);
> +exit_migrate_enable:
> + migrate_enable();
> return ret;
> }
>
> --
> 2.43.0
>
>
^ permalink raw reply
* RE: [PATCH v1 4/5] iommu/arm-smmu-v3-iommufd: Convert cache invalidation to the core array loop
From: Tian, Kevin @ 2026-07-03 6:30 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Jason Gunthorpe, Lu Baolu
Cc: Robin Murphy, joro@8bytes.org, David Woodhouse,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <0e89c623d10ba40e317067e304e30f52866fbe49.1782767398.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
>
> + if (ret) {
> + array->entry_num = 0;
> + return ret;
> + }
this could follow the mock driver to have a 'processed' variable and an
out label so above and several other places just use goto.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
^ permalink raw reply
* RE: [PATCH v1 5/5] iommu/vt-d: Convert nested cache invalidation to the core array loop
From: Tian, Kevin @ 2026-07-03 6:31 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Jason Gunthorpe, Lu Baolu
Cc: Robin Murphy, joro@8bytes.org, David Woodhouse,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <58eb6a9c1ba59ab3b4d1617adf697262f4c2a633.1782767398.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
>
> + /*
> + * The core re-invokes this op for the remaining requests, so handle
> one
> + * request per call. A zero-length array only probes the type,
> validated
> + * above.
> + */
> + if (!array->entry_num)
> + goto out;
ditto. just return 0 here.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
^ permalink raw reply
* RE: [PATCH v1 1/3] iommufd/viommu: Release the igroup lock on the vdevice_size error path
From: Tian, Kevin @ 2026-07-03 6:32 UTC (permalink / raw)
To: Nicolin Chen, Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, joro@8bytes.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <b0f848c60ce3337639d95362691c8e98522b7fda.1782767110.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
>
> iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the
> driver's vdevice_size against the core structure size with a WARN_ON_ONCE.
> On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it
> skips the mutex_unlock(), leaving the igroup lock held and deadlocking the
> next vDEVICE operation on that group.
>
> Jump to out_unlock_igroup instead.
>
> Fixes: ed42eee797ff3 ("iommufd/viommu: Add driver-defined vDEVICE
> support")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
^ permalink raw reply
* RE: [PATCH v1 2/3] iommufd/viommu: Publish a vDEVICE only after vdevice_init() succeeds
From: Tian, Kevin @ 2026-07-03 6:35 UTC (permalink / raw)
To: Nicolin Chen, Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, joro@8bytes.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <8f29de140d86bf507f71c6c27aee8e23e1c3940d.1782767110.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
>
> iommufd_vdevice_alloc_ioctl() adds the vDEVICE to the viommu->vdevs
> xarray
> with xa_cmpxchg() before the driver's vdevice_init() op runs. That op is
> where a driver validates the device and may reject it, but the xarray entry
> is already live by then: a concurrent IOMMU_HWPT_INVALIDATE can look it
> up
> with iommufd_viommu_find_dev() and run the driver invalidation path
> against
> a device that vdevice_init() would have refused.
>
> Reserve the index with xa_insert(): it stores a zero entry that reads back
> as NULL, and returns -EBUSY on a duplicate virt_id. Run vdevice_init() and
> store the vDEVICE pointer only once it succeeds. A failed vdevice_init()
> releases the reservation, so lookups observe the vDEVICE only after it is
> fully initialized and accepted.
>
> Fixes: ed42eee797ff3 ("iommufd/viommu: Add driver-defined vDEVICE
> support")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
cc stable
>
> if (viommu->ops && viommu->ops->vdevice_init) {
> rc = viommu->ops->vdevice_init(vdev);
> if (rc)
> - goto out_abort;
> + goto out_release;
> }
though correct, this causes an counter-intuitive error unwind
pattern with the following goto jumps to an outer label (out_abort).
It's cleaner to remove the new label by:
if (rc) {
xa_release(&viommu->vdevs, virt_id);
goto out_abort;
}
otherwise,
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: can: rockchip: add rk3588 CAN-FD compatible
From: Krzysztof Kozlowski @ 2026-07-03 6:39 UTC (permalink / raw)
To: Cunhao Lu
Cc: Marc Kleine-Budde, kernel, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <tencent_3E31CBEFAE0986665A26322171642BC00B05@qq.com>
On Fri, Jul 03, 2026 at 10:35:40AM +0800, Cunhao Lu wrote:
> RK3588 integrates a Rockchip CAN-FD controller variant that is not
> fully compatible with RK3568v2. The RX FIFO count register field is
> encoded in bits 7:5 on RK3588, while RK3568v2 uses bits 6:4.
>
> Add a dedicated rockchip,rk3588-canfd compatible to describe this
> variant. Do not use rockchip,rk3568v2-canfd as a fallback, because that
> would describe a register layout that does not match the hardware.
>
> Signed-off-by: Cunhao Lu <1579567540@qq.com>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v1 3/3] iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE
From: Tian, Kevin @ 2026-07-03 6:40 UTC (permalink / raw)
To: Nicolin Chen, Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, joro@8bytes.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <b98248fb8a7ba39beeb684d27f064897e6ec8ef6.1782767110.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
> }
>
> +static int arm_vsmmu_vdevice_init(struct iommufd_vdevice *vdev)
> +{
> + struct device *dev = iommufd_vdevice_to_device(vdev);
> + struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> +
> + /*
> + * arm_vsmmu_vsid_to_sid() maps a vSID to master->streams[0]
> alone, so
> + * more streams would leave the rest stale and none reads out of
> bounds.
> + */
> + if (master->num_streams != 1)
> + return -EINVAL;
> + return 0;
> +}
- EOPNOTSUPP, given the comment seems to indicate it as a current
limitation hence may be removed in future? otherwise with -EINVAL
this may be documented somewhere to get attention from userspace.
arm_vsmmu_vsid_to_sid()
/* At this moment, iommufd only supports PCI device that has one SID */
if (sid)
*sid = master->streams[0].id;
otherwise,
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: can: rockchip: add rk3588 CAN-FD compatible
From: Cunhao Lu @ 2026-07-03 6:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Marc Kleine-Budde, kernel, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260703-truthful-aardwolf-of-spirit-b6bafc@quoll>
Hi Krzysztof,
> > Add a dedicated rockchip,rk3588-canfd compatible to describe this
> > variant. Do not use rockchip,rk3568v2-canfd as a fallback, because that
> > would describe a register layout that does not match the hardware.
> >
> > Signed-off-by: Cunhao Lu <1579567540@qq.com>
> > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> > ---
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thanks for the ack. I will add your Acked-by tag to the binding patch
in v4.
Best regards,
Cunhao
^ permalink raw reply
* Re: [PATCH] mfd: stm32-timers: depopulate child devices on populate failure
From: Pengpeng Hou @ 2026-07-03 6:50 UTC (permalink / raw)
To: Lee Jones
Cc: Pengpeng Hou, Fabrice Gasnier, Maxime Coquelin, Alexandre Torgue,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260701214250.GD2108533@google.com>
Hi Lee,
Thanks for taking a look.
I checked devm_of_platform_populate(), but I don't think it covers this
particular failure path on its own.
devm_of_platform_populate() only installs the devres cleanup after
of_platform_populate() has returned success. If of_platform_populate()
returns an error after creating some earlier children, the helper just
frees its devres record and those partial children are not depopulated.
For stm32-timers, I think we still need the explicit ordering used by
remove: depopulate children before stm32_timers_dma_remove(). The child
drivers get the parent drvdata, and the PWM child can call the parent
stm32_timers_dma_burst_read() helper, so releasing the parent DMA
channels while partially-created children remain would keep the same
ordering problem the remove path avoids.
I agree the inline unwind is not the clearest form. I can send a v2
using a normal goto unwind label and a short comment explaining the
partial-populate case, unless you prefer a different shape.
Thanks,
Pengpeng
^ permalink raw reply
* [PATCH v7 00/16] arm64: support Engicam MicroGEA-STM32MP257-RMM board
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Alexandre Torgue, Amelie Delaunay, Arnd Bergmann,
Bjorn Andersson, Christophe Parant, Conor Dooley,
Dmitry Baryshkov, Eric Biggers, Geert Uytterhoeven,
Himanshu Bhavani, Krzysztof Kozlowski, Krzysztof Kozlowski,
Luca Weiss, Maxime Coquelin, Michal Simek, Rob Herring,
Sven Peter, devicetree, linux-arm-kernel, linux-stm32
This series adds initial support for the Engicam MicroGEA-STM32MP257-RMM
board based on the MicroGEA-STM32MP257 SoM.
The support includes device tree descriptions for both the SoM and the
carrier board, together with the required pinctrl definitions for the
peripherals used.
The series also updates the arm64 defconfig accordingly.
Changes in v7:
- Add Reviewed-by tag of Olivier Moysan to patch 10/16 "arm64: dts: st: add
sai1 pins for stm32mp25"
- Switch CONFIG_I2C_STM32F7 and CONFIG_SPI_STM32 to modules in
arch/arm64/configs/defconfig.
Changes in v6:
- Update arch/arm64/configs/defconfig to match the current upstream defconfig
after merge window changes (no functional changes).
Changes in v5:
- Add patch 2/16 arm64: dts: st: add power-domains to sdmmc1 on stm32mp231
- Add patch 3/16 arm64: dts: st: add power-domains to sdmmc1 on stm32mp251
- Increase slew-rate to <1> of ltdc pins to support the 27 MHz pixel clock
and prevent timing violations.
- Change SDMMC2_CK pin bias from pull-up to bias-disable to avoid signal
integrity issues on the clock line
- Fix touchscreen resolution to 480x854
- Fix SPI1 CS0 polarity to GPIO_ACTIVE_LOW
Changes in v4:
- Drop inclusion of stm32mp25xf.dtsi from stm32mp257-engicam-microgea.dtsi
Changes in v3:
- Add power-domains property in the SDMMC2 node.
- Drop patch "arm64: defconfig: cleanup the defconfig"
Changes in v2:
- Add Acked-by of Conor Dooley for patch 0/1 "dt-bindings: arm: stm32:
support Engicam MicroGEA-STM32MP257-RMM board"
- Add resets property to dts CAN node. Suggested by Sashiko.
- Drop the clocks property from the sai1 node in stm32mp257-engicam-microgea-rmm.dts
to avoid overriding the peripheral bus clock reference defined in the base
SoC device tree. Suggested by Sashiko.
- Reference the existing labeled nodes directly at the root level using
&sai1a and &sai1b in stm32mp257-engicam-microgea-rmm.dts instead of
redefining the entire node structure and redeclaring the labels. Suggested by Sashiko.
- Drop the #clock-cells property from sai1a and remove the reference to sai1a from
the clocks array in sai1b, relying strictly on the st,sync property to handle
internal synchronization.
Dario Binacchi (16):
dt-bindings: arm: stm32: support Engicam MicroGEA-STM32MP257-RMM board
arm64: dts: st: add power-domains to sdmmc1 on stm32mp231
arm64: dts: st: add power-domains to sdmmc1 on stm32mp251
arm64: dts: st: add SDMMC2 support on stm32mp25
arm64: dts: st: add CAN1 support on stm32mp25
arm64: dts: st: add i2c1 pins for stm32mp25
arm64: dts: st: add ltdc pins for stm32mp25
arm64: dts: st: add can1 pins for stm32mp25
arm64: dts: st: add pwm2/pwm4 pins for stm32mp25
arm64: dts: st: add sai1 pins for stm32mp25
arm64: dts: st: add sdmmc2 pins for stm32mp25
arm64: dts: st: add spi1 pins for stm32mp25
arm64: dts: st: add usart1 pins for stm32mp25
arm64: dts: st: support Engicam MicroGEA-STM32MP257 SoM
arm64: dts: st: support Engicam MicroGEA-STM32MP257-RMM board
arm64: defconfig: enable configs for Engicam MicroGEA-STM32MP257-RMM
.../devicetree/bindings/arm/stm32/stm32.yaml | 7 +
arch/arm64/boot/dts/st/Makefile | 1 +
arch/arm64/boot/dts/st/stm32mp231.dtsi | 1 +
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 328 ++++++++++++++++++
arch/arm64/boot/dts/st/stm32mp251.dtsi | 17 +
arch/arm64/boot/dts/st/stm32mp253.dtsi | 16 +
.../st/stm32mp257-engicam-microgea-rmm.dts | 319 +++++++++++++++++
.../dts/st/stm32mp257-engicam-microgea.dtsi | 63 ++++
arch/arm64/configs/defconfig | 4 +
9 files changed, 756 insertions(+)
create mode 100644 arch/arm64/boot/dts/st/stm32mp257-engicam-microgea-rmm.dts
create mode 100644 arch/arm64/boot/dts/st/stm32mp257-engicam-microgea.dtsi
--
2.43.0
base-commit: 4a50a141f05a8d1737661b19ee22ff8455b94409
branch: stm32mp257d-microgea
^ permalink raw reply
* [PATCH v7 01/16] dt-bindings: arm: stm32: support Engicam MicroGEA-STM32MP257-RMM board
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Conor Dooley, Alexandre Torgue, Amelie Delaunay,
Christophe Parant, Conor Dooley, Himanshu Bhavani,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260703065110.1433283-1-dario.binacchi@amarulasolutions.com>
Add devicetree bindings for Engicam MicroGEA-STM32MP257-RMM board based
on the Engicam MicroGEA-STM32MP257 SoM (System-on-Module).
The use of an enum for a single element is justified by the future
addition of other boards based on the same SoM.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
(no changes since v2)
Changes in v2:
- Add Acked-by of Conor Dooley for patch 0/1 "dt-bindings: arm: stm32:
support Engicam MicroGEA-STM32MP257-RMM board"
Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index c6af3a46364f..c5ce81e3ce45 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -203,6 +203,13 @@ properties:
- st,stm32mp257f-ev1
- const: st,stm32mp257
+ - description: Engicam MicroGEA STM32MP257 SoM based Boards
+ items:
+ - enum:
+ - engicam,microgea-stm32mp257-rmm
+ - const: engicam,microgea-stm32mp257
+ - const: st,stm32mp257
+
- description: ST STM32MP235 based Boards
items:
- enum:
--
2.43.0
^ permalink raw reply related
* [PATCH v7 02/16] arm64: dts: st: add power-domains to sdmmc1 on stm32mp231
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260703065110.1433283-1-dario.binacchi@amarulasolutions.com>
The sdmmc1 node was introduced early in the SoC bring-up before power
domains were systematically mapped. Add the missing power-domains
property to align it with the rest of the peripheral nodes.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v5)
Changes in v5:
- Added in version 5. Suggested by Sashiko.
arch/arm64/boot/dts/st/stm32mp231.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp231.dtsi b/arch/arm64/boot/dts/st/stm32mp231.dtsi
index 9e1d240888ff..0feb8943efae 100644
--- a/arch/arm64/boot/dts/st/stm32mp231.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp231.dtsi
@@ -727,6 +727,7 @@ sdmmc1: mmc@48220000 {
cap-mmc-highspeed;
max-frequency = <120000000>;
access-controllers = <&rifsc 76>;
+ power-domains = <&cluster_pd>;
status = "disabled";
};
--
2.43.0
^ permalink raw reply related
* [PATCH v7 03/16] arm64: dts: st: add power-domains to sdmmc1 on stm32mp251
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260703065110.1433283-1-dario.binacchi@amarulasolutions.com>
The sdmmc1 node was introduced early in the SoC bring-up before power
domains were systematically mapped. Add the missing power-domains
property to align it with the rest of the peripheral nodes.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v5)
Changes in v5:
- Added in version 5. Suggested by Sashiko.
arch/arm64/boot/dts/st/stm32mp251.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 9c63fdb5a885..ae36d703532c 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -1664,6 +1664,7 @@ sdmmc1: mmc@48220000 {
cap-mmc-highspeed;
max-frequency = <120000000>;
access-controllers = <&rifsc 76>;
+ power-domains = <&CLUSTER_PD>;
status = "disabled";
};
--
2.43.0
^ permalink raw reply related
* [PATCH v7 04/16] arm64: dts: st: add SDMMC2 support on stm32mp25
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260703065110.1433283-1-dario.binacchi@amarulasolutions.com>
The SDMMC2 controller supports SD cards, eMMC memories and SDIO devices.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v3)
Changes in v3:
- Add power-domains property. Suggested by Sashiko.
arch/arm64/boot/dts/st/stm32mp251.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index ae36d703532c..44938c036e30 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -1668,6 +1668,22 @@ sdmmc1: mmc@48220000 {
status = "disabled";
};
+ sdmmc2: mmc@48230000 {
+ compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00353180>;
+ reg = <0x48230000 0x400>, <0x44230800 0x8>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc CK_KER_SDMMC2>;
+ clock-names = "apb_pclk";
+ resets = <&rcc SDMMC2_R>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <120000000>;
+ access-controllers = <&rifsc 77>;
+ power-domains = <&CLUSTER_PD>;
+ status = "disabled";
+ };
+
ethernet1: ethernet@482c0000 {
compatible = "st,stm32mp25-dwmac", "snps,dwmac-5.20";
reg = <0x482c0000 0x4000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v7 05/16] arm64: dts: st: add CAN1 support on stm32mp25
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260703065110.1433283-1-dario.binacchi@amarulasolutions.com>
The controller is compliant with ISO 11898-1: 2015 (CAN protocol
specification version 2.0 part A, B) and CAN FD protocol specification
version 1.0.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v2)
Changes in v2:
- Add resets property to dts CAN node. Suggested by Sashiko.
arch/arm64/boot/dts/st/stm32mp253.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp253.dtsi b/arch/arm64/boot/dts/st/stm32mp253.dtsi
index eeceb086252b..7e82f01fdc10 100644
--- a/arch/arm64/boot/dts/st/stm32mp253.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp253.dtsi
@@ -43,6 +43,22 @@ &optee {
};
&rifsc {
+ m_can1: can@402d0000 {
+ compatible = "bosch,m_can";
+ reg = <0x402d0000 0x400>, <0x40310000 0xd50>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&rcc CK_BUS_FDCAN>, <&rcc CK_KER_FDCAN>;
+ clock-names = "hclk", "cclk";
+ resets = <&rcc FDCAN_R>;
+ bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+ access-controllers = <&rifsc 56>;
+ power-domains = <&CLUSTER_PD>;
+ status = "disabled";
+ };
+
ethernet2: ethernet@482d0000 {
compatible = "st,stm32mp25-dwmac", "snps,dwmac-5.20";
reg = <0x482d0000 0x4000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v7 06/16] arm64: dts: st: add i2c1 pins for stm32mp25
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260703065110.1433283-1-dario.binacchi@amarulasolutions.com>
Add the i2c1 pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v1)
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 456ece7f8ebc..db485b9ed904 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -203,6 +203,25 @@ pins {
};
};
+ /omit-if-no-ref/
+ i2c1_pins_a: i2c1-0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 13, AF9)>, /* I2C1_SCL */
+ <STM32_PINMUX('A', 2, AF10)>; /* I2C1_SDA */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
+ /omit-if-no-ref/
+ i2c1_sleep_pins_a: i2c1-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 13, ANALOG)>, /* I2C1_SCL */
+ <STM32_PINMUX('A', 2, ANALOG)>; /* I2C1_SDA */
+ };
+ };
+
/omit-if-no-ref/
i2c2_pins_a: i2c2-0 {
pins {
--
2.43.0
^ permalink raw reply related
* [PATCH v7 07/16] arm64: dts: st: add ltdc pins for stm32mp25
From: Dario Binacchi @ 2026-07-03 6:48 UTC (permalink / raw)
To: linux-kernel
Cc: michael, linux-amarula, francesco.utel, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260703065110.1433283-1-dario.binacchi@amarulasolutions.com>
Add the LTDC pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v5)
Changes in v5:
- Increase slew-rate to <1> to support the 27 MHz pixel clock and
prevent timing violations. Suggested by Sashiko
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 71 +++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index db485b9ed904..50f454630cf2 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -260,6 +260,77 @@ pins {
};
};
+ /omit-if-no-ref/
+ ltdc_pins_a: ltdc-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 6, AF14)>, /* LCD_CLK */
+ <STM32_PINMUX('G', 2, AF13)>, /* LCD_HSYNC */
+ <STM32_PINMUX('G', 1, AF13)>, /* LCD_VSYNC */
+ <STM32_PINMUX('C', 5, AF14)>, /* LCD_DE */
+ <STM32_PINMUX('H', 4, AF10)>, /* LCD_R0 */
+ <STM32_PINMUX('F', 7, AF13)>, /* LCD_R1 */
+ <STM32_PINMUX('C', 11, AF13)>, /* LCD_R2 */
+ <STM32_PINMUX('A', 1, AF11)>, /* LCD_R3 */
+ <STM32_PINMUX('B', 15, AF13)>, /* LCD_R4 */
+ <STM32_PINMUX('G', 3, AF13)>, /* LCD_R5 */
+ <STM32_PINMUX('A', 10, AF12)>, /* LCD_R6 */
+ <STM32_PINMUX('G', 7, AF13)>, /* LCD_R7 */
+ <STM32_PINMUX('F', 8, AF13)>, /* LCD_G0 */
+ <STM32_PINMUX('H', 5, AF10)>, /* LCD_G1 */
+ <STM32_PINMUX('C', 9, AF13)>, /* LCD_G2 */
+ <STM32_PINMUX('C', 10, AF13)>, /* LCD_G3 */
+ <STM32_PINMUX('A', 6, AF10)>, /* LCD_G4 */
+ <STM32_PINMUX('G', 11, AF13)>, /* LCD_G5 */
+ <STM32_PINMUX('G', 12, AF13)>, /* LCD_G6 */
+ <STM32_PINMUX('A', 9, AF12)>, /* LCD_G7 */
+ <STM32_PINMUX('F', 6, AF13)>, /* LCD_B0 */
+ <STM32_PINMUX('A', 3, AF11)>, /* LCD_B1 */
+ <STM32_PINMUX('G', 15, AF13)>, /* LCD_B2 */
+ <STM32_PINMUX('I', 0, AF13)>, /* LCD_B3 */
+ <STM32_PINMUX('I', 1, AF13)>, /* LCD_B4 */
+ <STM32_PINMUX('A', 7, AF10)>, /* LCD_B5 */
+ <STM32_PINMUX('F', 5, AF13)>, /* LCD_B6 */
+ <STM32_PINMUX('I', 4, AF13)>; /* LCD_B7 */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <1>;
+ };
+ };
+
+ /omit-if-no-ref/
+ ltdc_sleep_pins_a: ltdc-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 6, ANALOG)>, /* LCD_CLK */
+ <STM32_PINMUX('G', 2, ANALOG)>, /* LCD_HSYNC */
+ <STM32_PINMUX('G', 1, ANALOG)>, /* LCD_VSYNC */
+ <STM32_PINMUX('C', 5, ANALOG)>, /* LCD_DE */
+ <STM32_PINMUX('H', 4, ANALOG)>, /* LCD_R0 */
+ <STM32_PINMUX('F', 7, ANALOG)>, /* LCD_R1 */
+ <STM32_PINMUX('C', 11, ANALOG)>, /* LCD_R2 */
+ <STM32_PINMUX('A', 1, ANALOG)>, /* LCD_R3 */
+ <STM32_PINMUX('B', 15, ANALOG)>, /* LCD_R4 */
+ <STM32_PINMUX('G', 3, ANALOG)>, /* LCD_R5 */
+ <STM32_PINMUX('A', 10, ANALOG)>, /* LCD_R6 */
+ <STM32_PINMUX('G', 7, ANALOG)>, /* LCD_R7 */
+ <STM32_PINMUX('F', 8, ANALOG)>, /* LCD_G0 */
+ <STM32_PINMUX('H', 5, ANALOG)>, /* LCD_G1 */
+ <STM32_PINMUX('C', 9, ANALOG)>, /* LCD_G2 */
+ <STM32_PINMUX('C', 10, ANALOG)>, /* LCD_G3 */
+ <STM32_PINMUX('A', 6, ANALOG)>, /* LCD_G4 */
+ <STM32_PINMUX('G', 11, ANALOG)>, /* LCD_G5 */
+ <STM32_PINMUX('G', 12, ANALOG)>, /* LCD_G6 */
+ <STM32_PINMUX('A', 9, ANALOG)>, /* LCD_G7 */
+ <STM32_PINMUX('F', 6, ANALOG)>, /* LCD_B0 */
+ <STM32_PINMUX('A', 3, ANALOG)>, /* LCD_B1 */
+ <STM32_PINMUX('G', 15, ANALOG)>, /* LCD_B2 */
+ <STM32_PINMUX('I', 0, ANALOG)>, /* LCD_B3 */
+ <STM32_PINMUX('I', 1, ANALOG)>, /* LCD_B4 */
+ <STM32_PINMUX('A', 7, ANALOG)>, /* LCD_B5 */
+ <STM32_PINMUX('F', 5, ANALOG)>, /* LCD_B6 */
+ <STM32_PINMUX('I', 4, ANALOG)>; /* LCD_B7 */
+ };
+ };
+
/omit-if-no-ref/
ospi_port1_clk_pins_a: ospi-port1-clk-0 {
pins {
--
2.43.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