* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Dmitry Baryshkov @ 2026-03-23 22:12 UTC (permalink / raw)
To: Ayushi Makhija
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, dmitry.baryshkov, linux-arm-msm, devicetree,
linux-kernel, linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <20260323102229.1546504-1-quic_amakhija@quicinc.com>
On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
>
> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Please switch to oss.qualcomm.com
Other than that:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: vdso: fix AArch32 compat init allocation leaks
From: Andrew Morton @ 2026-03-23 22:29 UTC (permalink / raw)
To: Osama Abdelkader
Cc: Catalin Marinas, Will Deacon, Kees Cook, Liam R. Howlett, Jeff Xu,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260323214117.241216-1-osama.abdelkader@gmail.com>
On Mon, 23 Mar 2026 22:41:16 +0100 Osama Abdelkader <osama.abdelkader@gmail.com> wrote:
> aarch32_alloc_vdso_pages() allocates the AA32 vdso pagelist, the compat
> sigpage, then the kuser vectors page. If aarch32_alloc_sigpage() or
> aarch32_alloc_kuser_vdso_page() fails, earlier allocations were not freed.
>
> Unwind in reverse order: drop the sigpage when kuser setup fails, and
> kfree the vdso pagelist when either later step fails (only when
> CONFIG_COMPAT_VDSO allocated it).
Thanks. AI review has flagged a couple of possible issues:
https://sashiko.dev/#/patchset/20260323214117.241216-1-osama.abdelkader@gmail.com
^ permalink raw reply
* Re: [PATCH v6 20/40] arm_mpam: resctrl: Add CDP emulation
From: Gavin Shan @ 2026-03-23 22:35 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-21-ben.horgan@arm.com>
On 3/14/26 12:45 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> Intel RDT's CDP feature allows the cache to use a different control value
> depending on whether the accesses was for instruction fetch or a data
> access. MPAM's equivalent feature is the other way up: the CPU assigns a
> different partid label to traffic depending on whether it was instruction
> fetch or a data access, which causes the cache to use a different control
> value based solely on the partid.
>
> MPAM can emulate CDP, with the side effect that the alternative partid is
> seen by all MSC, it can't be enabled per-MSC.
>
> Add the resctrl hooks to turn this on or off. Add the helpers that match a
> closid against a task, which need to be aware that the value written to
> hardware is not the same as the one resctrl is using.
>
> Update the 'arm64_mpam_global_default' variable the arch code uses during
> context switch to know when the per-cpu value should be used instead. Also,
> update these per-cpu values and sync the resulting mpam partid/pmg
> configuration to hardware.
>
> resctrl can enable CDP for L2 caches, L3 caches or both. When it is enabled
> by one and not the other MPAM globally enabled CDP but hides the effect
> on the other cache resource. This hiding is possible as CPOR is the only
> supported cache control and that uses a resource bitmap; two partids with
> the same bitmap act as one.
>
> Awkwardly, the MB controls don't implement CDP and CDP can't be hidden as
> the memory bandwidth control is a maximum per partid which can't be
> modelled with more partids. If the total maximum is used for both the data
> and instruction partids then then the maximum may be exceeded and if it is
> split in two then the one using more bandwidth will hit a lower
> limit. Hence, hide the MB controls completely if CDP is enabled for any
> resource.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Cc: Dave Martin <Dave.Martin@arm.com>
> Cc: Amit Singh Tomar <amitsinght@marvell.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc:
> Fail cdp initialisation if there is only one partid
> Correct data/code confusion
>
> Changes since v2:
> Don't include unused header
>
> Changes since v3:
> Update the per-cpu values and sync to h/w
>
> Changes since v4:
> Enable separately for L2 and L3
> Disable MB controls if CDP enabled
> Consider cdp hiding in resctrl_arch_update_one()
>
> Changes since v5:
> Update comment on call sites
> ---
> arch/arm64/include/asm/mpam.h | 1 +
> drivers/resctrl/mpam_internal.h | 1 +
> drivers/resctrl/mpam_resctrl.c | 122 ++++++++++++++++++++++++++++++++
> include/linux/arm_mpam.h | 2 +
> 4 files changed, 126 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 21/40] arm_mpam: resctrl: Hide CDP emulation behind CONFIG_EXPERT
From: Gavin Shan @ 2026-03-23 22:36 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc
In-Reply-To: <20260313144617.3420416-22-ben.horgan@arm.com>
On 3/14/26 12:45 AM, Ben Horgan wrote:
> When CDP is not enabled, the 'rmid_entry's in the limbo list,
> rmid_busy_llc, map directly to a (PARTID,PMG) pair and when CDP is enabled
> the mapping is to two different pairs. As the limbo list is reused between
> mounts and CDP disabled on unmount this can lead to stale mapping and the
> limbo handler will then make monitor reads with potentially out of range
> PARTID. This may then cause an MPAM error interrupt and the driver will
> disable MPAM.
>
> No problems are expected if you just mount the resctrl file system
> once with CDP enabled and never unmount it. Hide CDP emulation behind
> CONFIG_EXPERT to protect the unwary.
>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Adding this ugliness in the hope of avoiding patch churn and extra
> reviewer work. I am looking into the resctrl changes needed to fix this.
> ---
> drivers/resctrl/mpam_resctrl.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v5 phy-next 09/27] scsi: ufs: exynos: stop poking into struct phy guts
From: Vladimir Oltean @ 2026-03-23 22:41 UTC (permalink / raw)
To: Alim Akhtar
Cc: 'Martin K. Petersen', linux-phy, 'Vinod Koul',
'Neil Armstrong', dri-devel, freedreno, linux-arm-kernel,
linux-arm-msm, linux-can, linux-gpio, linux-ide, linux-kernel,
linux-media, linux-pci, linux-renesas-soc, linux-riscv,
linux-rockchip, linux-samsung-soc, linux-scsi, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
'Bart Van Assche', 'Peter Griffin',
'James E.J. Bottomley', 'Krzysztof Kozlowski',
'Chanho Park'
In-Reply-To: <1891546521.01774280282025.JavaMail.epsvc@epcpadp2new>
On Mon, Mar 23, 2026 at 06:05:36PM +0530, Alim Akhtar wrote:
> Will review and possibly test on one of the board later tonight
Ok, in that case I'll wait. Thanks.
^ permalink raw reply
* Re: (subset) [PATCH v2 0/6] TQMa91/TQMa93: display support on MBa91xxCA
From: Frank Li @ 2026-03-23 22:46 UTC (permalink / raw)
To: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abel Vesa, Peng Fan,
Michael Turquette, Stephen Boyd, Alexander Stein
Cc: Frank Li, imx, linux-arm-kernel, devicetree, linux-kernel, linux,
linux-clk
In-Reply-To: <20260313070740.585043-1-alexander.stein@ew.tq-group.com>
On Fri, 13 Mar 2026 08:07:30 +0100, Alexander Stein wrote:
> this series adds support for parallel and LVDS displays on MBa91xxCA, both for
> TQMa91 and TQMa93. The parallel display is attached directly, while the LVDS
> uses an LVDS-Encoder. To actually work it needs the pdfc driver from [1].
>
> The first two patches add required (Video) PLL configurations to achieve the
> necessary pixel clocks for both displays.
> The last 4 patches add the overlays for TQMa91 and TQMa93, although the
> overlays for TQMa91 use the same overlay for TQMa93.
>
> [...]
Applied, thanks!
[3/6] arm64: dts: imx93-tqma9352-mba91xxca: Add parallel display overlay
commit: 57e546efd0948d9b580cb7b8824ea62b16af4cb7
[4/6] arm64: dts: imx93-tqma9352-mba91xxca: Add LVDS display overlay
commit: d6b12b4c49a11baed9b4de98f333f731aab6bf9d
[5/6] arm64: dts: imx91-tqma9131-mba91xxca: Add parallel display overlay
commit: d99156ff8bcb5607c7688dde5a55315ea818b150
[6/6] arm64: dts: imx91-tqma9131-mba91xxca: Add LVDS display overlay
commit: 10d12c22336cc7477142fddbe0b17111797fc68c
Update commit message by change "This adds" => Add ...
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v6 22/40] arm_mpam: resctrl: Convert to/from MPAMs fixed-point formats
From: Gavin Shan @ 2026-03-23 22:49 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-23-ben.horgan@arm.com>
Hi Ben,
On 3/14/26 12:45 AM, Ben Horgan wrote:
> From: Dave Martin <Dave.Martin@arm.com>
>
> MPAM uses a fixed-point formats for some hardware controls. Resctrl
> provides the bandwidth controls as a percentage. Add helpers to convert
> between these.
>
> Ensure bwa_wd is at most 16 to make it clear higher values have no meaning.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v2:
> Ensure bwa_wd is at most 16 (moved from patch 40: arm_mpam: Generate a
> configuration for min controls)
> Expand comments
> ---
> drivers/resctrl/mpam_devices.c | 7 +++++
> drivers/resctrl/mpam_resctrl.c | 51 ++++++++++++++++++++++++++++++++++
> 2 files changed, 58 insertions(+)
>
One nitpick below, but this looks good to me in either way.
Reviewed-by: Gavin Shan <gshan@redhat.com>
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 0e5e24ef60fe..0c97f7708722 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -713,6 +713,13 @@ static void mpam_ris_hw_probe(struct mpam_msc_ris *ris)
> mpam_set_feature(mpam_feat_mbw_part, props);
>
> props->bwa_wd = FIELD_GET(MPAMF_MBW_IDR_BWA_WD, mbw_features);
> +
> + /*
> + * The BWA_WD field can represent 0-63, but the control fields it
> + * describes have a maximum of 16 bits.
> + */
> + props->bwa_wd = min(props->bwa_wd, 16);
> +
16 may deserve a definition for it since it's a constant value and referred
for multiple times in this patch, if we need to give this series another
respin :-)
> if (props->bwa_wd && FIELD_GET(MPAMF_MBW_IDR_HAS_MAX, mbw_features))
> mpam_set_feature(mpam_feat_mbw_max, props);
>
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index cab3e9ccb5c7..adaec522c1a1 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -10,6 +10,7 @@
> #include <linux/errno.h>
> #include <linux/limits.h>
> #include <linux/list.h>
> +#include <linux/math.h>
> #include <linux/printk.h>
> #include <linux/rculist.h>
> #include <linux/resctrl.h>
> @@ -242,6 +243,56 @@ static bool cache_has_usable_cpor(struct mpam_class *class)
> return class->props.cpbm_wd <= 32;
> }
>
> +/*
> + * Each fixed-point hardware value architecturally represents a range
> + * of values: the full range 0% - 100% is split contiguously into
> + * (1 << cprops->bwa_wd) equal bands.
> + *
> + * Although the bwa_bwd fields have 6 bits the maximum valid value is 16
> + * as it reports the width of fields that are at most 16 bits. When
> + * fewer than 16 bits are valid the least significant bits are
> + * ignored. The implied binary point is kept between bits 15 and 16 and
> + * so the valid bits are leftmost.
> + *
> + * See ARM IHI0099B.a "MPAM system component specification", Section 9.3,
> + * "The fixed-point fractional format" for more information.
> + *
> + * Find the nearest percentage value to the upper bound of the selected band:
> + */
> +static u32 mbw_max_to_percent(u16 mbw_max, struct mpam_props *cprops)
> +{
> + u32 val = mbw_max;
> +
> + val >>= 16 - cprops->bwa_wd;
> + val += 1;
> + val *= MAX_MBA_BW;
> + val = DIV_ROUND_CLOSEST(val, 1 << cprops->bwa_wd);
> +
> + return val;
> +}
> +
> +/*
> + * Find the band whose upper bound is closest to the specified percentage.
> + *
> + * A round-to-nearest policy is followed here as a balanced compromise
> + * between unexpected under-commit of the resource (where the total of
> + * a set of resource allocations after conversion is less than the
> + * expected total, due to rounding of the individual converted
> + * percentages) and over-commit (where the total of the converted
> + * allocations is greater than expected).
> + */
> +static u16 percent_to_mbw_max(u8 pc, struct mpam_props *cprops)
> +{
> + u32 val = pc;
> +
> + val <<= cprops->bwa_wd;
> + val = DIV_ROUND_CLOSEST(val, MAX_MBA_BW);
> + val = max(val, 1) - 1;
> + val <<= 16 - cprops->bwa_wd;
> +
> + return val;
> +}
> +
> /* Test whether we can export MPAM_CLASS_CACHE:{2,3}? */
> static void mpam_resctrl_pick_caches(void)
> {
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH v6 23/40] arm_mpam: resctrl: Add rmid index helpers
From: Gavin Shan @ 2026-03-23 22:50 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-24-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> Because MPAM's pmg aren't identical to RDT's rmid, resctrl handles some
> data structures by index. This allows x86 to map indexes to RMID, and MPAM
> to map them to partid-and-pmg.
>
> Add the helpers to do this.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Suggested-by: James Morse <james.morse@arm.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc:
> Use ~0U instead of ~0 in lhs of left shift
>
> Changes since v2:
> Drop changes signed-off-by as reworked patch
> Use multiply and add rather than shift to avoid holes
> ---
> drivers/resctrl/mpam_resctrl.c | 16 ++++++++++++++++
> include/linux/arm_mpam.h | 3 +++
> 2 files changed, 19 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: (subset) [PATCH 0/3] ARM: dts: imx: clean imx25 tsadc related CHECK_DTBS warnings
From: Frank Li @ 2026-03-23 22:52 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Frank Li
Cc: linux-input, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260211-yaml_mfd-v1-0-05cb48bc6f09@nxp.com>
On Wed, 11 Feb 2026 16:41:03 -0500, Frank Li wrote:
> Clean imx25 tsadc related warnings.
> - convert txt to yaml.
> - rename nodename to touchscreen.
>
>
Applied, thanks!
[3/3] ARM: dts: imx25: rename node name tcq to touchscreen
commit: b2166e73d9ac16189db629589d229eb94558e420
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v6 24/40] arm_mpam: resctrl: Wait for cacheinfo to be ready
From: Gavin Shan @ 2026-03-23 22:53 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-25-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> In order to calculate the rmid realloc threshold the size of the cache
> needs to be known. Cache domains will also be named after the cache id. So
> that this information can be extracted from cacheinfo we need to wait for
> it to be ready. The cacheinfo information is populated in device_initcall()
> so we wait for that.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> [horgan: split out from another patch]
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> This is moved into it's own patch to allow all uses of cacheinfo to be
> valid when they are introduced.
> ---
> drivers/resctrl/mpam_resctrl.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH 1/4] exec: inherit HWCAPs from the parent process
From: Marek Szyprowski @ 2026-03-23 22:59 UTC (permalink / raw)
To: Andrei Vagin, Kees Cook, Andrew Morton
Cc: Cyrill Gorcunov, Mike Rapoport, Alexander Mikhalitsyn,
linux-kernel, linux-fsdevel, linux-mm, criu, Catalin Marinas,
Will Deacon, linux-arm-kernel, Chen Ridong, Christian Brauner,
David Hildenbrand, Eric Biederman, Lorenzo Stoakes, Michal Koutny,
Alexander Mikhalitsyn
In-Reply-To: <20260323175340.3361311-2-avagin@google.com>
On 23.03.2026 18:53, Andrei Vagin wrote:
> Introduces a mechanism to inherit hardware capabilities (AT_HWCAP,
> AT_HWCAP2, etc.) from a parent process when they have been modified via
> prctl.
>
> To support C/R operations (snapshots, live migration) in heterogeneous
> clusters, we must ensure that processes utilize CPU features available
> on all potential target nodes. To solve this, we need to advertise a
> common feature set across the cluster.
>
> This patch adds a new mm flag MMF_USER_HWCAP, which is set when the
> auxiliary vector is modified via prctl(PR_SET_MM, PR_SET_MM_AUXV). When
> execve() is called, if the current process has MMF_USER_HWCAP set, the
> HWCAP values are extracted from the current auxiliary vector and stored
> in the linux_binprm structure. These values are then used to populate
> the auxiliary vector of the new process, effectively inheriting the
> hardware capabilities.
>
> The inherited HWCAPs are masked with the hardware capabilities supported
> by the current kernel to ensure that we don't report more features than
> actually supported. This is important to avoid unexpected behavior,
> especially for processes with additional privileges.
>
> Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>
> Reviewed-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> Signed-off-by: Andrei Vagin <avagin@google.com>
v5 fixed the issue I've observed here:
https://lore.kernel.org/all/aec9c36d-d67a-4b61-9950-57b95afedf75@samsung.com/
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> fs/binfmt_elf.c | 13 ++++++---
> fs/binfmt_elf_fdpic.c | 13 ++++++---
> fs/exec.c | 62 ++++++++++++++++++++++++++++++++++++++++
> include/linux/binfmts.h | 11 +++++++
> include/linux/mm_types.h | 2 ++
> kernel/fork.c | 3 ++
> kernel/sys.c | 5 +++-
> 7 files changed, 100 insertions(+), 9 deletions(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index fb857faaf0d6..d99db73c76f0 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -183,6 +183,7 @@ create_elf_tables(struct linux_binprm *bprm, const struct elfhdr *exec,
> int ei_index;
> const struct cred *cred = current_cred();
> struct vm_area_struct *vma;
> + bool user_hwcap = mm_flags_test(MMF_USER_HWCAP, mm);
>
> /*
> * In some cases (e.g. Hyper-Threading), we want to avoid L1
> @@ -247,7 +248,8 @@ create_elf_tables(struct linux_binprm *bprm, const struct elfhdr *exec,
> */
> ARCH_DLINFO;
> #endif
> - NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> + NEW_AUX_ENT(AT_HWCAP, user_hwcap ?
> + (bprm->hwcap & ELF_HWCAP) : ELF_HWCAP);
> NEW_AUX_ENT(AT_PAGESZ, ELF_EXEC_PAGESIZE);
> NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
> NEW_AUX_ENT(AT_PHDR, phdr_addr);
> @@ -265,13 +267,16 @@ create_elf_tables(struct linux_binprm *bprm, const struct elfhdr *exec,
> NEW_AUX_ENT(AT_SECURE, bprm->secureexec);
> NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
> #ifdef ELF_HWCAP2
> - NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> + NEW_AUX_ENT(AT_HWCAP2, user_hwcap ?
> + (bprm->hwcap2 & ELF_HWCAP2) : ELF_HWCAP2);
> #endif
> #ifdef ELF_HWCAP3
> - NEW_AUX_ENT(AT_HWCAP3, ELF_HWCAP3);
> + NEW_AUX_ENT(AT_HWCAP3, user_hwcap ?
> + (bprm->hwcap3 & ELF_HWCAP3) : ELF_HWCAP3);
> #endif
> #ifdef ELF_HWCAP4
> - NEW_AUX_ENT(AT_HWCAP4, ELF_HWCAP4);
> + NEW_AUX_ENT(AT_HWCAP4, user_hwcap ?
> + (bprm->hwcap4 & ELF_HWCAP4) : ELF_HWCAP4);
> #endif
> NEW_AUX_ENT(AT_EXECFN, bprm->exec);
> if (k_platform) {
> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index 95b65aab7daa..92c88471455a 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -508,6 +508,7 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
> unsigned long flags = 0;
> int ei_index;
> elf_addr_t *elf_info;
> + bool user_hwcap = mm_flags_test(MMF_USER_HWCAP, mm);
>
> #ifdef CONFIG_MMU
> /* In some cases (e.g. Hyper-Threading), we want to avoid L1 evictions
> @@ -629,15 +630,19 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
> */
> ARCH_DLINFO;
> #endif
> - NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> + NEW_AUX_ENT(AT_HWCAP, user_hwcap ?
> + (bprm->hwcap & ELF_HWCAP) : ELF_HWCAP);
> #ifdef ELF_HWCAP2
> - NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> + NEW_AUX_ENT(AT_HWCAP2, user_hwcap ?
> + (bprm->hwcap2 & ELF_HWCAP2) : ELF_HWCAP2);
> #endif
> #ifdef ELF_HWCAP3
> - NEW_AUX_ENT(AT_HWCAP3, ELF_HWCAP3);
> + NEW_AUX_ENT(AT_HWCAP3, user_hwcap ?
> + (bprm->hwcap3 & ELF_HWCAP3) : ELF_HWCAP3);
> #endif
> #ifdef ELF_HWCAP4
> - NEW_AUX_ENT(AT_HWCAP4, ELF_HWCAP4);
> + NEW_AUX_ENT(AT_HWCAP4, user_hwcap ?
> + (bprm->hwcap4 & ELF_HWCAP4) : ELF_HWCAP4);
> #endif
> NEW_AUX_ENT(AT_PAGESZ, PAGE_SIZE);
> NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
> diff --git a/fs/exec.c b/fs/exec.c
> index 9ea3a775d51e..1cd7d87a0e79 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1775,6 +1775,65 @@ static int bprm_execve(struct linux_binprm *bprm)
> return retval;
> }
>
> +static void inherit_hwcap(struct linux_binprm *bprm)
> +{
> + struct mm_struct *mm = current->mm;
> + bool compat = in_compat_syscall();
> + int i, n;
> +
> +#ifdef ELF_HWCAP4
> + n = 4;
> +#elif defined(ELF_HWCAP3)
> + n = 3;
> +#elif defined(ELF_HWCAP2)
> + n = 2;
> +#else
> + n = 1;
> +#endif
> +
> + for (i = 0; n && i < AT_VECTOR_SIZE; i += 2) {
> + unsigned long type, val;
> +
> + if (!compat) {
> + type = mm->saved_auxv[i];
> + val = mm->saved_auxv[i + 1];
> + } else {
> + compat_uptr_t *auxv = (compat_uptr_t *)mm->saved_auxv;
> +
> + type = auxv[i];
> + val = auxv[i + 1];
> + }
> +
> + switch (type) {
> + case AT_NULL:
> + goto done;
> + case AT_HWCAP:
> + bprm->hwcap = val;
> + break;
> +#ifdef ELF_HWCAP2
> + case AT_HWCAP2:
> + bprm->hwcap2 = val;
> + break;
> +#endif
> +#ifdef ELF_HWCAP3
> + case AT_HWCAP3:
> + bprm->hwcap3 = val;
> + break;
> +#endif
> +#ifdef ELF_HWCAP4
> + case AT_HWCAP4:
> + bprm->hwcap4 = val;
> + break;
> +#endif
> + default:
> + continue;
> + }
> + n--;
> + }
> +done:
> + mm_flags_set(MMF_USER_HWCAP, bprm->mm);
> +}
> +
> static int do_execveat_common(int fd, struct filename *filename,
> struct user_arg_ptr argv,
> struct user_arg_ptr envp,
> @@ -1843,6 +1902,9 @@ static int do_execveat_common(int fd, struct filename *filename,
> current->comm, bprm->filename);
> }
>
> + if (mm_flags_test(MMF_USER_HWCAP, current->mm))
> + inherit_hwcap(bprm);
> +
> return bprm_execve(bprm);
> }
>
> diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
> index 65abd5ab8836..94a3dcf9b1d2 100644
> --- a/include/linux/binfmts.h
> +++ b/include/linux/binfmts.h
> @@ -2,6 +2,7 @@
> #ifndef _LINUX_BINFMTS_H
> #define _LINUX_BINFMTS_H
>
> +#include <linux/elf.h>
> #include <linux/sched.h>
> #include <linux/unistd.h>
> #include <asm/exec.h>
> @@ -67,6 +68,16 @@ struct linux_binprm {
> unsigned long exec;
>
> struct rlimit rlim_stack; /* Saved RLIMIT_STACK used during exec. */
> + unsigned long hwcap;
> +#ifdef ELF_HWCAP2
> + unsigned long hwcap2;
> +#endif
> +#ifdef ELF_HWCAP3
> + unsigned long hwcap3;
> +#endif
> +#ifdef ELF_HWCAP4
> + unsigned long hwcap4;
> +#endif
>
> char buf[BINPRM_BUF_SIZE];
> } __randomize_layout;
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 3cc8ae722886..62dde645f469 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -1919,6 +1919,8 @@ enum {
> #define MMF_TOPDOWN 31 /* mm searches top down by default */
> #define MMF_TOPDOWN_MASK BIT(MMF_TOPDOWN)
>
> +#define MMF_USER_HWCAP 32 /* user-defined HWCAPs */
> +
> #define MMF_INIT_LEGACY_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\
> MMF_DISABLE_THP_MASK | MMF_HAS_MDWE_MASK |\
> MMF_VM_MERGE_ANY_MASK | MMF_TOPDOWN_MASK)
> diff --git a/kernel/fork.c b/kernel/fork.c
> index bc2bf58b93b6..2ac277aa078c 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1105,6 +1105,9 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
>
> __mm_flags_overwrite_word(mm, mmf_init_legacy_flags(flags));
> mm->def_flags = current->mm->def_flags & VM_INIT_DEF_MASK;
> +
> + if (mm_flags_test(MMF_USER_HWCAP, current->mm))
> + mm_flags_set(MMF_USER_HWCAP, mm);
> } else {
> __mm_flags_overwrite_word(mm, default_dump_filter);
> mm->def_flags = 0;
> diff --git a/kernel/sys.c b/kernel/sys.c
> index cdbf8513caf6..e4b0fa2f6845 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2157,8 +2157,10 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
> * not introduce additional locks here making the kernel
> * more complex.
> */
> - if (prctl_map.auxv_size)
> + if (prctl_map.auxv_size) {
> memcpy(mm->saved_auxv, user_auxv, sizeof(user_auxv));
> + mm_flags_set(MMF_USER_HWCAP, mm);
> + }
>
> mmap_read_unlock(mm);
> return 0;
> @@ -2190,6 +2192,7 @@ static int prctl_set_auxv(struct mm_struct *mm, unsigned long addr,
>
> task_lock(current);
> memcpy(mm->saved_auxv, user_auxv, len);
> + mm_flags_set(MMF_USER_HWCAP, mm);
> task_unlock(current);
>
> return 0;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: freescale: imx93: Add Ethos-U65 NPU and SRAM nodes
From: Frank Li @ 2026-03-23 23:03 UTC (permalink / raw)
To: Forrest Shi, Peng Fan, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring (Arm)
Cc: Frank Li, Peter Robinson, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260306203103.3119790-1-robh@kernel.org>
On Fri, 06 Mar 2026 14:31:02 -0600, Rob Herring (Arm) wrote:
> i.MX93 contains an Arm Ethos-U65 NPU. The NPU uses the internal SRAM for
> temporary buffers. The SRAM is larger than 96KB, but that is all that is
> available to non-secure world.
>
>
Applied, thanks!
[1/1] arm64: dts: freescale: imx93: Add Ethos-U65 NPU and SRAM nodes
commit: c95a5c0b55664ff938371b058673f294ce01fe1b
Move sram@20480000 node after soc@0 because keep order by address
Fix line assigned-clock-parents to keep below 100 char to avoid checkpatch
warning.
About sram size discussion, we can fix later.
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v6 25/40] arm_mpam: resctrl: Add support for 'MB' resource
From: Gavin Shan @ 2026-03-23 23:09 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-26-ben.horgan@arm.com>
Hi Ben,
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> resctrl supports 'MB', as a percentage throttling of traffic from the
> L3. This is the control that mba_sc uses, so ideally the class chosen
> should be as close as possible to the counters used for mbm_total. If there
> is a single L3, it's the last cache, and the topology of the memory matches
> then the traffic at the memory controller will be equivalent to that at
> egress of the L3. If these conditions are met allow the memory class to
> back MB.
>
> MB's percentage control should be backed either with the fixed point
> fraction MBW_MAX or bandwidth portion bitmaps. The bandwidth portion
> bitmaps is not used as its tricky to pick which bits to use to avoid
> contention, and may be possible to expose this as something other than a
> percentage in the future.
>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Co-developed-by: Dave Martin <Dave.Martin@arm.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Signed-off-by: James Morse <james.morse@arm.com>>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v2:
> Code flow change
> Commit message 'or'
>
> Changes since v3:
> initialise tmp_cpumask
> update commit message
> check the traffic matches l3
> update comment on candidate_class update, only mbm_total
> drop tags due to rework
>
> Changes since v4:
> Move __free declarations to point of first use
> New line for a '{'
> set r->alloc_capable last (Reinette)
>
> Changes since v5:
> Mention L3 needs to be the last cache in commit message
> Consider memory side caches and numa nodes
> ---
> drivers/resctrl/mpam_resctrl.c | 287 ++++++++++++++++++++++++++++++++-
> 1 file changed, 286 insertions(+), 1 deletion(-)
>
One comment below and it deserves to be addressed if we have another respin:
Reviewed-by: Gavin Shan <gshan@redhat.com>
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index 93c8a9608ed4..cad65cf7d12d 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -267,6 +267,33 @@ static bool cache_has_usable_cpor(struct mpam_class *class)
> return class->props.cpbm_wd <= 32;
> }
>
> +static bool mba_class_use_mbw_max(struct mpam_props *cprops)
> +{
> + return (mpam_has_feature(mpam_feat_mbw_max, cprops) &&
> + cprops->bwa_wd);
> +}
> +
> +static bool class_has_usable_mba(struct mpam_props *cprops)
> +{
> + return mba_class_use_mbw_max(cprops);
> +}
> +
> +/*
> + * Calculate the worst-case percentage change from each implemented step
> + * in the control.
> + */
> +static u32 get_mba_granularity(struct mpam_props *cprops)
> +{
> + if (!mba_class_use_mbw_max(cprops))
> + return 0;
> +
> + /*
> + * bwa_wd is the number of bits implemented in the 0.xxx
> + * fixed point fraction. 1 bit is 50%, 2 is 25% etc.
> + */
> + return DIV_ROUND_UP(MAX_MBA_BW, 1 << cprops->bwa_wd);
> +}
> +
> /*
> * Each fixed-point hardware value architecturally represents a range
> * of values: the full range 0% - 100% is split contiguously into
> @@ -317,6 +344,166 @@ static u16 percent_to_mbw_max(u8 pc, struct mpam_props *cprops)
> return val;
> }
>
> +static u32 get_mba_min(struct mpam_props *cprops)
> +{
> + if (!mba_class_use_mbw_max(cprops)) {
> + WARN_ON_ONCE(1);
> + return 0;
> + }
> +
> + return mbw_max_to_percent(0, cprops);
> +}
> +
> +/* Find the L3 cache that has affinity with this CPU */
> +static int find_l3_equivalent_bitmask(int cpu, cpumask_var_t tmp_cpumask)
> +{
> + u32 cache_id = get_cpu_cacheinfo_id(cpu, 3);
> +
> + lockdep_assert_cpus_held();
> +
> + return mpam_get_cpumask_from_cache_id(cache_id, 3, tmp_cpumask);
> +}
> +
> +/*
> + * topology_matches_l3() - Is the provided class the same shape as L3
> + * @victim: The class we'd like to pretend is L3.
> + *
> + * resctrl expects all the world's a Xeon, and all counters are on the
> + * L3. We allow some mapping counters on other classes. This requires
> + * that the CPU->domain mapping is the same kind of shape.
> + *
> + * Using cacheinfo directly would make this work even if resctrl can't
> + * use the L3 - but cacheinfo can't tell us anything about offline CPUs.
> + * Using the L3 resctrl domain list also depends on CPUs being online.
> + * Using the mpam_class we picked for L3 so we can use its domain list
> + * assumes that there are MPAM controls on the L3.
> + * Instead, this path eventually uses the mpam_get_cpumask_from_cache_id()
> + * helper which can tell us about offline CPUs ... but getting the cache_id
> + * to start with relies on at least one CPU per L3 cache being online at
> + * boot.
> + *
> + * Walk the victim component list and compare the affinity mask with the
> + * corresponding L3. The topology matches if each victim:component's affinity
> + * mask is the same as the CPU's corresponding L3's. These lists/masks are
> + * computed from firmware tables so don't change at runtime.
> + */
> +static bool topology_matches_l3(struct mpam_class *victim)
> +{
> + int cpu, err;
> + struct mpam_component *victim_iter;
> +
> + lockdep_assert_cpus_held();
> +
> + cpumask_var_t __free(free_cpumask_var) tmp_cpumask = CPUMASK_VAR_NULL;
> + if (!alloc_cpumask_var(&tmp_cpumask, GFP_KERNEL))
> + return false;
> +
> + guard(srcu)(&mpam_srcu);
> + list_for_each_entry_srcu(victim_iter, &victim->components, class_list,
> + srcu_read_lock_held(&mpam_srcu)) {
> + if (cpumask_empty(&victim_iter->affinity)) {
> + pr_debug("class %u has CPU-less component %u - can't match L3!\n",
> + victim->level, victim_iter->comp_id);
> + return false;
> + }
> +
> + cpu = cpumask_any_and(&victim_iter->affinity, cpu_online_mask);
> + if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
> + return false;
> +
> + cpumask_clear(tmp_cpumask);
> + err = find_l3_equivalent_bitmask(cpu, tmp_cpumask);
> + if (err) {
> + pr_debug("Failed to find L3's equivalent component to class %u component %u\n",
> + victim->level, victim_iter->comp_id);
> + return false;
> + }
> +
> + /* Any differing bits in the affinity mask? */
> + if (!cpumask_equal(tmp_cpumask, &victim_iter->affinity)) {
> + pr_debug("class %u component %u has Mismatched CPU mask with L3 equivalent\n"
> + "L3:%*pbl != victim:%*pbl\n",
> + victim->level, victim_iter->comp_id,
> + cpumask_pr_args(tmp_cpumask),
> + cpumask_pr_args(&victim_iter->affinity));
> +
> + return false;
> + }
> + }
> +
> + return true;
> +}
> +
> +/*
> + * Test if the traffic for a class matches that at egress from the L3. For
> + * MSC at memory controllers this is only possible if there is a single L3
> + * as otherwise the counters at the memory can include bandwidth from the
> + * non-local L3.
> + */
> +static bool traffic_matches_l3(struct mpam_class *class)
> +{
> + int err, cpu;
> +
> + lockdep_assert_cpus_held();
> +
> + if (class->type == MPAM_CLASS_CACHE && class->level == 3)
> + return true;
> +
> + if (class->type == MPAM_CLASS_CACHE && class->level != 3) {
> + pr_debug("class %u is a different cache from L3\n", class->level);
> + return false;
> + }
> +
> + if (class->type != MPAM_CLASS_MEMORY) {
> + pr_debug("class %u is neither of type cache or memory\n", class->level);
> + return false;
> + }
> +
We bail if the calss isn't MPAM_CLASS_MEMORY here ...
> + cpumask_var_t __free(free_cpumask_var) tmp_cpumask = CPUMASK_VAR_NULL;
> + if (!alloc_cpumask_var(&tmp_cpumask, GFP_KERNEL)) {
> + pr_debug("cpumask allocation failed\n");
> + return false;
> + }
> +
> + if (class->type != MPAM_CLASS_MEMORY) {
> + pr_debug("class %u is neither of type cache or memory\n",
> + class->level);
> + return false;
> + }
> +
Duplicated check here as the previous one. So this check can be dropped.
> + cpu = cpumask_any_and(&class->affinity, cpu_online_mask);
> + err = find_l3_equivalent_bitmask(cpu, tmp_cpumask);
> + if (err) {
> + pr_debug("Failed to find L3 downstream to cpu %d\n", cpu);
> + return false;
> + }
> +
> + if (!cpumask_equal(tmp_cpumask, cpu_possible_mask)) {
> + pr_debug("There is more than one L3\n");
> + return false;
> + }
> +
> + /* Be strict; the traffic might stop in the intermediate cache. */
> + if (get_cpu_cacheinfo_id(cpu, 4) != -1) {
> + pr_debug("L3 isn't the last level of cache\n");
> + return false;
> + }
> +
> + if (num_possible_nodes() > 1) {
> + pr_debug("There is more than one numa node\n");
> + return false;
> + }
> +
> +#ifdef CONFIG_HMEM_REPORTING
> + if (node_devices[cpu_to_node(cpu)]->cache_dev) {
> + pr_debug("There is a memory side cache\n");
> + return false;
> + }
> +#endif
> +
> + return true;
> +}
> +
> /* Test whether we can export MPAM_CLASS_CACHE:{2,3}? */
> static void mpam_resctrl_pick_caches(void)
> {
> @@ -358,9 +545,68 @@ static void mpam_resctrl_pick_caches(void)
> }
> }
>
> +static void mpam_resctrl_pick_mba(void)
> +{
> + struct mpam_class *class, *candidate_class = NULL;
> + struct mpam_resctrl_res *res;
> +
> + lockdep_assert_cpus_held();
> +
> + guard(srcu)(&mpam_srcu);
> + list_for_each_entry_srcu(class, &mpam_classes, classes_list,
> + srcu_read_lock_held(&mpam_srcu)) {
> + struct mpam_props *cprops = &class->props;
> +
> + if (class->level != 3 && class->type == MPAM_CLASS_CACHE) {
> + pr_debug("class %u is a cache but not the L3\n", class->level);
> + continue;
> + }
> +
> + if (!class_has_usable_mba(cprops)) {
> + pr_debug("class %u has no bandwidth control\n",
> + class->level);
> + continue;
> + }
> +
> + if (!cpumask_equal(&class->affinity, cpu_possible_mask)) {
> + pr_debug("class %u has missing CPUs\n", class->level);
> + continue;
> + }
> +
> + if (!topology_matches_l3(class)) {
> + pr_debug("class %u topology doesn't match L3\n",
> + class->level);
> + continue;
> + }
> +
> + if (!traffic_matches_l3(class)) {
> + pr_debug("class %u traffic doesn't match L3 egress\n",
> + class->level);
> + continue;
> + }
> +
> + /*
> + * Pick a resource to be MBA that as close as possible to
> + * the L3. mbm_total counts the bandwidth leaving the L3
> + * cache and MBA should correspond as closely as possible
> + * for proper operation of mba_sc.
> + */
> + if (!candidate_class || class->level < candidate_class->level)
> + candidate_class = class;
> + }
> +
> + if (candidate_class) {
> + pr_debug("selected class %u to back MBA\n",
> + candidate_class->level);
> + res = &mpam_resctrl_controls[RDT_RESOURCE_MBA];
> + res->class = candidate_class;
> + }
> +}
> +
> static int mpam_resctrl_control_init(struct mpam_resctrl_res *res)
> {
> struct mpam_class *class = res->class;
> + struct mpam_props *cprops = &class->props;
> struct rdt_resource *r = &res->resctrl_res;
>
> switch (r->rid) {
> @@ -392,6 +638,19 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res)
> r->cache.shareable_bits = resctrl_get_default_ctrl(r);
> r->alloc_capable = true;
> break;
> + case RDT_RESOURCE_MBA:
> + r->schema_fmt = RESCTRL_SCHEMA_RANGE;
> + r->ctrl_scope = RESCTRL_L3_CACHE;
> +
> + r->membw.delay_linear = true;
> + r->membw.throttle_mode = THREAD_THROTTLE_UNDEFINED;
> + r->membw.min_bw = get_mba_min(cprops);
> + r->membw.max_bw = MAX_MBA_BW;
> + r->membw.bw_gran = get_mba_granularity(cprops);
> +
> + r->name = "MB";
> + r->alloc_capable = true;
> + break;
> default:
> return -EINVAL;
> }
> @@ -406,7 +665,17 @@ static int mpam_resctrl_pick_domain_id(int cpu, struct mpam_component *comp)
> if (class->type == MPAM_CLASS_CACHE)
> return comp->comp_id;
>
> - /* TODO: repaint domain ids to match the L3 domain ids */
> + if (topology_matches_l3(class)) {
> + /* Use the corresponding L3 component ID as the domain ID */
> + int id = get_cpu_cacheinfo_id(cpu, 3);
> +
> + /* Implies topology_matches_l3() made a mistake */
> + if (WARN_ON_ONCE(id == -1))
> + return comp->comp_id;
> +
> + return id;
> + }
> +
> /* Otherwise, expose the ID used by the firmware table code. */
> return comp->comp_id;
> }
> @@ -446,6 +715,12 @@ u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> case RDT_RESOURCE_L3:
> configured_by = mpam_feat_cpor_part;
> break;
> + case RDT_RESOURCE_MBA:
> + if (mpam_has_feature(mpam_feat_mbw_max, cprops)) {
> + configured_by = mpam_feat_mbw_max;
> + break;
> + }
> + fallthrough;
> default:
> return resctrl_get_default_ctrl(r);
> }
> @@ -457,6 +732,8 @@ u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> switch (configured_by) {
> case mpam_feat_cpor_part:
> return cfg->cpbm;
> + case mpam_feat_mbw_max:
> + return mbw_max_to_percent(cfg->mbw_max, cprops);
> default:
> return resctrl_get_default_ctrl(r);
> }
> @@ -504,6 +781,13 @@ int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> cfg.cpbm = cfg_val;
> mpam_set_feature(mpam_feat_cpor_part, &cfg);
> break;
> + case RDT_RESOURCE_MBA:
> + if (mpam_has_feature(mpam_feat_mbw_max, cprops)) {
> + cfg.mbw_max = percent_to_mbw_max(cfg_val, cprops);
> + mpam_set_feature(mpam_feat_mbw_max, &cfg);
> + break;
> + }
> + fallthrough;
> default:
> return -EINVAL;
> }
> @@ -775,6 +1059,7 @@ int mpam_resctrl_setup(void)
>
> /* Find some classes to use for controls */
> mpam_resctrl_pick_caches();
> + mpam_resctrl_pick_mba();
>
> /* Initialise the resctrl structures from the classes */
> for_each_mpam_resctrl_control(res, rid) {
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH v6 26/40] arm_mpam: resctrl: Add kunit test for control format conversions
From: Gavin Shan @ 2026-03-23 23:10 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-27-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: Dave Martin <Dave.Martin@arm.com>
>
> resctrl specifies the format of the control schemes, and these don't match
> the hardware.
>
> Some of the conversions are a bit hairy - add some kunit tests.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> [morse: squashed enough of Dave's fixes in here that it's his patch now!]
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v2:
> Include additional values from the latest spec
> ---
> drivers/resctrl/mpam_resctrl.c | 4 +
> drivers/resctrl/test_mpam_resctrl.c | 315 ++++++++++++++++++++++++++++
> 2 files changed, 319 insertions(+)
> create mode 100644 drivers/resctrl/test_mpam_resctrl.c
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/2] Kontron i.MX8MP OSM Devicetree Fixups
From: Frank Li @ 2026-03-23 23:18 UTC (permalink / raw)
To: Alexandre Belloni, Conor Dooley, devicetree, Frieder Schrempf,
imx, Krzysztof Kozlowski, linux-arm-kernel, linux-kernel,
linux-rtc, Rob Herring, Sascha Hauer, Shawn Guo, Frieder Schrempf
Cc: Frank Li, Annette Kobou, Fabio Estevam, Pengutronix Kernel Team
In-Reply-To: <20260309085749.25747-1-frieder@fris.de>
On Mon, 09 Mar 2026 09:57:41 +0100, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> This contains three fixes and one cosmetic change for
> the Kontron i.MX8MP OSM devices.
>
> Changes for v3:
> * Drop applied patches
> * Add missing bindings patch for RV3028 RTC
>
> [...]
Applied, thanks!
[2/2] arm64: dts: imx8mp-kontron: Fix boot order for PMIC and RTC
commit: 0f02852af55591d6a8609347890cc348f86fdac9
Update commit messsage, adjust wrap at 75 char. Change "this fixes" to
avoid. Remove "We can ..."
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 1/1] ARM: dts: imx6sx: remove fallback compatible string fsl,imx28-lcdif
From: Frank Li @ 2026-03-23 23:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Frank Li
Cc: imx, Liu Ying
In-Reply-To: <20260311194111.2918037-1-Frank.Li@nxp.com>
On Wed, 11 Mar 2026 15:41:11 -0400, Frank Li wrote:
> The i.MX6SX LCDIF is not fully compatible with the i.MX28 LCDIF. The
> i.MX6SX controller provides additional overlay registers (AS_CTRL) which
> are not present on i.MX28.
>
> Linux has supported the dedicated compatible string since commit
> 45d59d704080 ("drm: Add new driver for MXSFB controller").
>
> [...]
Applied, thanks!
[1/1] ARM: dts: imx6sx: remove fallback compatible string fsl,imx28-lcdif
commit: 2031fc524eb2805ec3eaa972041ba5cb27b8d707
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 1/2] iommu/arm-smmu-v3: Do not continue in __arm_smmu_domain_inv_range()
From: Jason Gunthorpe @ 2026-03-23 23:39 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <20260321225041.11090-2-nicolinc@nvidia.com>
On Sat, Mar 21, 2026 at 03:50:40PM -0700, Nicolin Chen wrote:
> The loop in the __arm_smmu_domain_inv_range() is a while loop, not a for
> loop. So, using "continue" is wrong that would fail to move the needle.
>
> Meanwhile, though the current command is skipped, the batch still has to
> go through arm_smmu_invs_end_batch() to be issued accordingly.
>
> Thus, use "break" to fix the issue.
>
> Fixes: 587bb3e56a2c ("iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range()")
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: sun55i: Fix r-spi DMA
From: Jernej Škrabec @ 2026-03-23 23:49 UTC (permalink / raw)
To: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: linux-sunxi, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260323171927.1256507-1-wens@kernel.org>
Dne ponedeljek, 23. marec 2026 ob 18:19:26 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> r-spi has DRQs for both the main and MCU DMA controllers on the A523 SoC
> family, however it seems it that it is mainly routed to the MCU DMA
> controller, with no obvious way to change it.
>
> Change the DMA channels of r-spi to the MCU so that it works properly.
>
> Fixes: 1bec3bd1f839 ("arm64: dts: allwinner: sun55i: Add SPI controllers")
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH] ASoC: sun4i-spdif: Make reset control non-optional and check for all errors
From: Jernej Škrabec @ 2026-03-23 23:50 UTC (permalink / raw)
To: Philipp Zabel, Mark Brown, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Chen-Yu Tsai
Cc: Chen-Yu Tsai, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260323172450.1259111-1-wens@kernel.org>
Dne ponedeljek, 23. marec 2026 ob 18:24:48 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai <wens@csie.org>
>
> The logic around the reset control is weird. The driver already has
> quirks describing which compatible strings require a reset control, but
> the reset control is acquired using the "optional" API. Then any errors
> other than deferred probe are ignored.
>
> Instead, switch to the non-optional variant. Also use the deassered
> variant to simplify the code. This also fixes a missing reset assert
> upon removal.
>
> Last, clean up the error message printing with dev_err_probe().
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v2 4/7] iommu/arm-smmu-v3: Mark ATC invalidate timeouts via lockless bitmap
From: Jason Gunthorpe @ 2026-03-23 23:51 UTC (permalink / raw)
To: Nicolin Chen
Cc: Tian, Kevin, Samiullah Khawaja, will@kernel.org,
robin.murphy@arm.com, joro@8bytes.org, bhelgaas@google.com,
rafael@kernel.org, lenb@kernel.org, praan@google.com,
baolu.lu@linux.intel.com, xueshuai@linux.alibaba.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-pci@vger.kernel.org, Vikram Sethi
In-Reply-To: <abtphBuLiXxSxmAy@Asurada-Nvidia>
On Wed, Mar 18, 2026 at 08:12:04PM -0700, Nicolin Chen wrote:
> > > VT-d is able to find out the SID of the device for which the device TLB
> > > invalidation timed-out occured by using the SID reported in the
> > > "Invalidation Queue Error Record Register" (VT-d Specs 11.4.9.9).
> >
> > yes. but when there are multiple submissions (each with a wait descriptor)
> > fetched/handled by the hw and then an invalidation timeout comes, all
> > pending wait descriptors will be aborted (not just the one corresponding
> > to the timeout). In this case all affected submitters need to re-try.
>
> This sounds similar to SMMU then.
Not entirely.. smmu HW stops processing at a SYNC and waits for
everything pending to complete, then goes on forward. If there is a HW
reported ATC timeout then it is contained to the SYNC that followed
the ATC invalidation. The errored sync is skipped and whatever follows
continues forward, so it doesn't contaminate future work.
VT-d's wait descriptor with fence FN=1 sounds identical???
I guess if FN=0 then things start to become indeterminate what the
wait actually waits for..
Jason
^ permalink raw reply
* Re: [PATCH v2 4/7] iommu/arm-smmu-v3: Mark ATC invalidate timeouts via lockless bitmap
From: Jason Gunthorpe @ 2026-03-23 23:57 UTC (permalink / raw)
To: Nicolin Chen
Cc: Samiullah Khawaja, will, robin.murphy, joro, bhelgaas, rafael,
lenb, praan, baolu.lu, xueshuai, kevin.tian, linux-arm-kernel,
iommu, linux-kernel, linux-acpi, linux-pci, vsethi
In-Reply-To: <abs0CQCrFlCsV6Ls@Asurada-Nvidia>
On Wed, Mar 18, 2026 at 04:23:53PM -0700, Nicolin Chen wrote:
> If the software times out first at 1s, it means the CMDQ is still
> pending on wait for the completion of ATC invalidation. Then, the
> caller sees -ETIMEOUT and tries to bisect the ATC batch or update
> the STE directly, either of which involves CMDQ. But CMDQ has not
> recovered yet.
Yeah, I don't know if the SW timeout flow is really all that RASy here
right now. Without somehow recovering the CMDQ it is pointless to try
to continue after a timeout.
And we are really in trouble if things like normal IOTLB invalidation
start to fail.
I think the right thing is to somehow try to recover the cmdq and then
restart it on the commands that haven't been SYNC'd yet and just keep
trying, maybe with progressively longer timeouts.
Just ignoring the error and continuing doesn't seem safe.
But that's something else again, as long as ATC invalidation reliably
hits the HW timeout first we should be OK to ignore it in this
series..
Jason
^ permalink raw reply
* Re: [PATCH v2 0/7] iommu/arm-smmu-v3: Quarantine device upon ATC invalidation timeout
From: Jason Gunthorpe @ 2026-03-24 0:03 UTC (permalink / raw)
To: Nicolin Chen
Cc: Tian, Kevin, will@kernel.org, robin.murphy@arm.com,
joro@8bytes.org, bhelgaas@google.com, rafael@kernel.org,
lenb@kernel.org, praan@google.com, baolu.lu@linux.intel.com,
xueshuai@linux.alibaba.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
Vikram Sethi
In-Reply-To: <abtpCXAnqLRnbG1z@Asurada-Nvidia>
On Wed, Mar 18, 2026 at 08:10:01PM -0700, Nicolin Chen wrote:
> On Thu, Mar 19, 2026 at 02:29:38AM +0000, Tian, Kevin wrote:
> > > > > This series addresses a critical vulnerability and stability issue where an
> > > > > unresponsive PCIe device failing to process ATC (Address Translation
> > > Cache)
> > > > > invalidation requests leads to silent data corruption and continuous
> > > SMMU
> > > > > CMDQ error spam.
> > > > >
> > > >
> > > > None of the patches in this series contains a Fixed tag and cc stable.
> > >
> > > Hmm, I guess AI overly polished the cover letter so it sounds too
> > > strong?
> > >
> > > This is essentially a vulnerability (potential memory corruption).
> > > And none of these patches actually fixes any regression. The PATCH
> > > 7 even requires the arm_smmu_invs series which has not been merged
> > > yet :-/
> > >
> >
> > Fixes tag and backporting are not just for regression. People certainly
> > want to see reported vulnerabilities fixed in stable kernels...
>
> Well, maybe I'll just leave additional line telling people that this
> can't be a bug "fix" because it's written on another unmerged series?
I think this is more of a feature (RAS support for SMMUv3) than a
specific fix.
Jason
^ permalink raw reply
* Re: (subset) [PATCH v5 00/17] cleanup in spi by use devm_clk_get_enabled
From: Mark Brown @ 2026-03-23 19:47 UTC (permalink / raw)
To: linux-spi, linux-arm-kernel, linux-kernel, imx, openbmc,
linux-rockchip, linux-riscv, linux-mediatek, linux-stm32,
Frank.Li, amelie.delaunay, Pei Xiao
In-Reply-To: <cover.1773885292.git.xiaopei01@kylinos.cn>
On Thu, 19 Mar 2026 10:03:56 +0800, Pei Xiao wrote:
> cleanup in spi by use devm_clk_get_enabled
>
> I know that many old SPI drivers should not be modified for hardware
> stability and to reduce maintenance effort. But I can't help cleaning them
> up. To minimize the introduction of issues, I tried not to modify the
> timing of those hardware clock enables.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[02/17] spi: bcm63xx-hsspi: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/e532e21a246d
[03/17] spi: bcmbca-hsspi: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/8b237cb10e32
[09/17] spi: sifive: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/140039c23aca
[13/17] spi: stm32: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/7da637804805
[14/17] spi: sunplus-sp7021: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/ea0e916de134
[15/17] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/fbf34af0c6eb
[16/17] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/c9a4136c4746
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 0/2] regulator: cros-ec: cleanup and add supplies
From: Mark Brown @ 2026-03-23 22:39 UTC (permalink / raw)
To: Liam Girdwood, Benson Leung, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chen-Yu Tsai
Cc: linux-arm-kernel, linux-mediatek, devicetree, chrome-platform
In-Reply-To: <20260320083135.2455444-1-wenst@chromium.org>
On Fri, 20 Mar 2026 16:31:31 +0800, Chen-Yu Tsai wrote:
> regulator: cros-ec: cleanup and add supplies
>
> Hi,
>
> This series is part of a broader collection of regulator related
> cleanups for MediaTek Chromebooks. This one covers the regulators
> exposed by the ChromeOS Embedded Controller.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[1/2] regulator: dt-bindings: cros-ec: Add regulator supply
https://git.kernel.org/broonie/regulator/c/56b7c08a8b4b
[2/2] regulator: cros-ec: Add regulator supply
https://git.kernel.org/broonie/regulator/c/411eb30f1382
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] spi: pl022: update outdated references to pump_transfers()
From: Mark Brown @ 2026-03-23 18:11 UTC (permalink / raw)
To: linusw, linux-arm-kernel, linux-spi, linux-kernel, Kexin Sun
Cc: julia.lawall, xutong.ma, yunbolyu, ratnadiraw
In-Reply-To: <20260321105940.8143-1-kexinsun@smail.nju.edu.cn>
On Sat, 21 Mar 2026 18:59:40 +0800, Kexin Sun wrote:
> spi: pl022: update outdated references to pump_transfers()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[1/1] spi: pl022: update outdated references to pump_transfers()
https://git.kernel.org/broonie/spi/c/a37fb5166be9
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ 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