* Re: [GIT,PULL,2/3] MediaTek SoC driver updates for v7.2
From: Krzysztof Kozlowski @ 2026-06-09 10:42 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: arm-soc, soc, linux-arm-kernel, linux-mediatek, matthias.bgg,
matthias.bgg
In-Reply-To: <20260601091225.5223-3-angelogioacchino.delregno@collabora.com>
On Mon, Jun 01, 2026 at 11:12:22AM +0200, AngeloGioacchino Del Regno wrote:
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/ tags/mtk-soc-for-v7.2
>
> for you to fetch changes up to 7d462de9f65b002b439b1b168bf3b5579b0de48b:
>
> soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge (2026-05-11 11:20:48 +0200)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] ufs: mediatek: Implement get_hba_nortt callback for RTT capability
From: ed.tsai @ 2026-06-09 10:38 UTC (permalink / raw)
To: alim.akhtar, avri.altman, bvanassche, James.Bottomley,
martin.petersen, linux-scsi
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
peter.wang, alice.chao, naomi.chu, chun-hung.wu, Ed Tsai
In-Reply-To: <20260609103856.676222-1-ed.tsai@mediatek.com>
From: Ed Tsai <ed.tsai@mediatek.com>
Implement the get_hba_nortt callback to handle platform-specific RTT
capability differences:
- For legacy platforms and IP versions before MT6995 B0, the RTT
capability from host controller register is problematic, so limit
it to 2 (MTK_MAX_NUM_RTT_LEGACY).
- For MT6995 B0 and later platforms, the issue is fixed and the
value from host controller capability register can be used directly.
This replaces the previous max_num_rtt field in ufs_hba_variant_ops
with dynamic platform-specific logic.
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
---
drivers/ufs/host/ufs-mediatek.c | 12 +++++++++++-
drivers/ufs/host/ufs-mediatek.h | 4 ++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index 3991a51263a6..58701ca95edd 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -2183,6 +2183,16 @@ static int ufs_mtk_clk_scale_notify(struct ufs_hba *hba, bool scale_up,
return 0;
}
+static int ufs_mtk_get_hba_nortt(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ if (host->legacy_ip_ver || host->ip_ver < IP_VER_MT6995_B0)
+ return MTK_MAX_NUM_RTT_LEGACY;
+
+ return FIELD_GET(MASK_NUMBER_OUTSTANDING_RTT, hba->capabilities) + 1;
+}
+
static int ufs_mtk_get_hba_mac(struct ufs_hba *hba)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
@@ -2322,7 +2332,6 @@ static void ufs_mtk_config_scsi_dev(struct scsi_device *sdev)
*/
static const struct ufs_hba_variant_ops ufs_hba_mtk_vops = {
.name = "mediatek.ufshci",
- .max_num_rtt = MTK_MAX_NUM_RTT,
.init = ufs_mtk_init,
.get_ufs_hci_version = ufs_mtk_get_ufs_hci_version,
.setup_clocks = ufs_mtk_setup_clocks,
@@ -2339,6 +2348,7 @@ static const struct ufs_hba_variant_ops ufs_hba_mtk_vops = {
.event_notify = ufs_mtk_event_notify,
.config_scaling_param = ufs_mtk_config_scaling_param,
.clk_scale_notify = ufs_mtk_clk_scale_notify,
+ .get_hba_nortt = ufs_mtk_get_hba_nortt,
/* mcq vops */
.get_hba_mac = ufs_mtk_get_hba_mac,
.op_runtime_config = ufs_mtk_op_runtime_config,
diff --git a/drivers/ufs/host/ufs-mediatek.h b/drivers/ufs/host/ufs-mediatek.h
index 8547a6f04990..73cdc726f290 100644
--- a/drivers/ufs/host/ufs-mediatek.h
+++ b/drivers/ufs/host/ufs-mediatek.h
@@ -203,8 +203,8 @@ struct ufs_mtk_host {
/* MTK delay of autosuspend: 500 ms */
#define MTK_RPM_AUTOSUSPEND_DELAY_MS 500
-/* MTK RTT support number */
-#define MTK_MAX_NUM_RTT 2
+/* MTK RTT support number for platforms before MT6995 B0 */
+#define MTK_MAX_NUM_RTT_LEGACY 2
/* UFSHCI MTK ip version value */
enum {
--
2.45.2
^ permalink raw reply related
* [PATCH 0/2] ufs: Add callback for vendor-specific RTT capability
From: ed.tsai @ 2026-06-09 10:38 UTC (permalink / raw)
To: alim.akhtar, avri.altman, bvanassche, James.Bottomley,
martin.petersen, linux-scsi
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
peter.wang, alice.chao, naomi.chu, chun-hung.wu, Ed Tsai
From: Ed Tsai <ed.tsai@mediatek.com>
The first patch adds the get_hba_nortt() callback to the UFS core layer
and removes the static max_num_rtt field from ufs_hba_variant_ops. This
allows platform vendors to provide dynamic, platform-specific RTT capability
handling.
The second patch implements this callback in the MediaTek UFS driver,
distinguishing between legacy and newer platforms.
Ed Tsai (2):
ufs: core: Add get_hba_nortt callback for vendor-specific RTT
capability
ufs: mediatek: Implement get_hba_nortt callback for RTT capability
drivers/ufs/core/ufshcd.c | 9 +++++----
drivers/ufs/host/ufs-mediatek.c | 12 +++++++++++-
drivers/ufs/host/ufs-mediatek.h | 4 ++--
include/ufs/ufshcd.h | 5 +++--
4 files changed, 21 insertions(+), 9 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH 1/2] ufs: core: Add get_hba_nortt callback for vendor-specific RTT capability
From: ed.tsai @ 2026-06-09 10:38 UTC (permalink / raw)
To: alim.akhtar, avri.altman, bvanassche, James.Bottomley,
martin.petersen, linux-scsi
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
peter.wang, alice.chao, naomi.chu, chun-hung.wu, Ed Tsai
In-Reply-To: <20260609103856.676222-1-ed.tsai@mediatek.com>
From: Ed Tsai <ed.tsai@mediatek.com>
The number of outstanding RTTs read from host controller capability
register is problematic on some platforms. Add a new vendor callback
get_hba_nortt() to allow platform vendors to override the default RTT
capability value with platform-specific handling.
For platforms without the callback, continue to use the value from the
host controller capability register.
Also remove the max_num_rtt field from ufs_hba_variant_ops as it is
replaced by the new get_hba_nortt callback.
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
---
drivers/ufs/core/ufshcd.c | 9 +++++----
include/ufs/ufshcd.h | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index c3f08957d179..00072bff9dcd 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -2529,7 +2529,10 @@ static inline int ufshcd_hba_capabilities(struct ufs_hba *hba)
hba->nutmrs =
((hba->capabilities & MASK_TASK_MANAGEMENT_REQUEST_SLOTS) >> 16) + 1;
- hba->nortt = FIELD_GET(MASK_NUMBER_OUTSTANDING_RTT, hba->capabilities) + 1;
+ if (hba->vops && hba->vops->get_hba_nortt)
+ hba->nortt = hba->vops->get_hba_nortt(hba);
+ else
+ hba->nortt = FIELD_GET(MASK_NUMBER_OUTSTANDING_RTT, hba->capabilities) + 1;
/* Read crypto capabilities */
err = ufshcd_hba_init_crypto_capabilities(hba);
@@ -8554,8 +8557,6 @@ static void ufshcd_set_rtt(struct ufs_hba *hba)
struct ufs_dev_info *dev_info = &hba->dev_info;
u32 rtt = 0;
u32 dev_rtt = 0;
- int host_rtt_cap = hba->vops && hba->vops->max_num_rtt ?
- hba->vops->max_num_rtt : hba->nortt;
/* RTT override makes sense only for UFS-4.0 and above */
if (dev_info->wspecversion < 0x400)
@@ -8571,7 +8572,7 @@ static void ufshcd_set_rtt(struct ufs_hba *hba)
if (dev_rtt != DEFAULT_MAX_NUM_RTT)
return;
- rtt = min_t(int, dev_info->rtt_cap, host_rtt_cap);
+ rtt = min_t(int, dev_info->rtt_cap, hba->nortt);
if (rtt == dev_rtt)
return;
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index cfbc75d8df83..13d0d7798294 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -370,7 +370,6 @@ struct ufshcd_tx_eq_params {
/**
* struct ufs_hba_variant_ops - variant specific callbacks
* @name: variant name
- * @max_num_rtt: maximum RTT supported by the host
* @init: called when the driver is initialized
* @exit: called to cleanup everything done in init
* @set_dma_mask: For setting another DMA mask than indicated by the 64AS
@@ -415,10 +414,11 @@ struct ufshcd_tx_eq_params {
* @get_rx_fom: called to get Figure of Merit (FOM) value.
* @tx_eqtr_notify: called before and after TX Equalization Training procedure
* to allow platform vendor specific configs to take place.
+ * @get_hba_nortt: called to get maximum number of outstanding RTTs supported by
+ * the controller.
*/
struct ufs_hba_variant_ops {
const char *name;
- int max_num_rtt;
int (*init)(struct ufs_hba *);
void (*exit)(struct ufs_hba *);
u32 (*get_ufs_hci_version)(struct ufs_hba *);
@@ -477,6 +477,7 @@ struct ufs_hba_variant_ops {
int (*tx_eqtr_notify)(struct ufs_hba *hba,
enum ufs_notify_change_status status,
struct ufs_pa_layer_attr *pwr_mode);
+ int (*get_hba_nortt)(struct ufs_hba *hba);
};
/* clock gating state */
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v3 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE
From: Marek Szyprowski @ 2026-06-09 10:35 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <86ik7st3nh.wl-maz@kernel.org>
On 09.06.2026 12:21, Marc Zyngier wrote:
> On Tue, 09 Jun 2026 11:03:21 +0100,
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> On 23.05.2026 16:02, Marc Zyngier wrote:
>>> When running with at EL2 with VHE enabled, the architecture provides
>>> two EL2 timer/counters, dubbed physical and virtual. Apart from their
>>> names, they are strictly identical.
>>>
>>> However, they don't get virtualised the same way, specially when
>>> it comes to adding arbitrary offsets to the timers. When running as
>>> a guest, the host CNTVOFF_EL2 does apply to the guest's view of
>>> CNTHV*_El2. This is not true for CNTPOFF_EL2 and CNTHP*_EL2, as
>>> the architecture is broken past the first level of virtualisation
>>> (it lacks some essential mechanisms to be usable, despite what
>>> the ARM ARM pretends).
>>>
>>> This means that when running as a L2 guest hypervisor, using the
>>> physical timer results in traps to L0, which are then forwarded to
>>> L1 in order to emulate the offset, leading to even worse performance
>>> due to massive trap amplification (the combination of register and
>>> ERET trapping is absolutely lethal).
>>>
>>> Switch the arch timer code to using the virtual timer when running
>>> in VHE by default, only using the physical timer if the interrupt
>>> is not correctly described in the firmware tables (which seems
>>> to be an unfortunately common case). This comes as no impact on
>>> bare-metal, and slightly improves the situation in the virtualised
>>> case.
>>>
>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> This patch landed recently in linux-next as commit d87773de9efe
>> ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when
>> running VHE"). In my tests I found that it breaks booting of RaspberryPi5
>> board. Reverting it on top of linux-next fixes the issue. Here is a boot
>> log:
> Huh.
>
> [...]
>
>> arch_timer: cp15 timer running at 54.00MHz (hyp-virt).
>> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
>> sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
> The interrupt appears to be advertised in the DT, but doesn't seem to
> fire. That's obviously not going to end well. My suspicion is that
> either the interrupt isn't wired (that'd be hilariously abd), or is
> left as Group-0 by the firmware (copy-paste from RPi4).
>
> Can you try the following hack and let me know if the kernel shouts at
> you?
>
> Thanks,
>
> M.
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index ec70c84e9f91d..d05791e6cc0db 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -213,6 +213,7 @@ static void gic_eoimode1_mask_irq(struct irq_data *d)
> static void gic_unmask_irq(struct irq_data *d)
> {
> gic_poke_irq(d, GIC_DIST_ENABLE_SET);
> + WARN_ON(!gic_peek_irq(d, GIC_DIST_ENABLE_SET));
> }
>
> static void gic_eoi_irq(struct irq_data *d)
I've applied this change, but it doesn't trigger any warning in the boot log.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Pranjal Shrivastava @ 2026-06-09 10:34 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rAWZ4Ac23D8eyAHfmaVVkHv8pz45+_dpMO1M4D7+RVCoA@mail.gmail.com>
On Sun, Jun 07, 2026 at 03:22:19PM -0700, Daniel Mentz wrote:
> On Wed, Jun 3, 2026 at 11:27 PM Pranjal Shrivastava <praan@google.com> wrote:
> >
> > On Wed, Jun 03, 2026 at 01:28:19PM -0700, Daniel Mentz wrote:
> > > On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> > > > @@ -2361,8 +2394,33 @@ static irqreturn_t arm_smmu_handle_gerror(struct arm_smmu_device *smmu)
> > > > static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev)
> > > > {
> > > > struct arm_smmu_device *smmu = dev;
> > > > + irqreturn_t ret;
> > > > +
> > > > + /*
> > > > + * Global Errors are only processed if the SMMU is active.
> > > > + *
> > > > + * If the STOP_FLAG is set (can_elide == true), the hardware is
> > > > + * either already disabled or in the process of being disabled.
> > > > + * Any errors captured during the quiesce/drain phase will be
> > > > + * handled by the explicit arm_smmu_handle_gerror() call at the
> > > > + * end of arm_smmu_runtime_suspend() callback. On resume, the
> > > > + * STOP_FLAG is cleared before interrupts are re-enabled, ensuring
> > > > + * no valid errors are missed.
> > > > + *
> > > > + * A lockless check is favoured here over a dynamic PM core check
> > > > + * since the runtime_pm_get_if_active would return false during
> > > > + * transient states like RPM_RESUMING & ignore level-triggered
> > > > + * interrupts.
> > > > + */
> > > > + if (arm_smmu_cmdq_can_elide(smmu)) {
> > > > + dev_err(smmu->dev,
> > > > + "Ignoring gerror interrupt because the SMMU is suspended\n");
> > > > + return IRQ_NONE;
> > > > + }
> > >
> > > Have you considered using arm_smmu_rpm_get() here instead?
> > > I can see two issues with the currenlty proposal:
> > > * Returning IRQ_NONE when an interrupt is indeed active and needs to
> > > be handled. This might be interpreted as a spurious interrupt
> > > * Nothing is preventing the suspend handler from running while
> > > arm_smmu_gerror_handler is in the middle of handling an interrupt
> > >
> > > I understand that using arm_smmu_rpm_get() also has downsides,
> > > including an unnecessary resume operation when the SMMU is already in
> > > RPM_SUSPENDING state. However, using arm_smmu_rpm_get() would make it
> > > easier to ensure correctness.
> > >
> >
> > I don't think using arm_smmu_rpm_get() here is possible..
> >
> > GERROR is registered as a hard IRQ handler, so calling rpm_get (which
> > can sleep) would be wrong.
>
> You're right. Sorry, I missed that arm_smmu_gerror_handler is
> registered as a hard irq handler.
>
> > Regarding the race, the STOP_FLAG is set at the very beginning of the
> > suspend sequence. If an IRQ fires after that, we return IRQ_NONE and
> > let the explicit arm_smmu_handle_gerror() call at the end of
> > runtime_suspend catch and clear it. After CMDQEN, PRIQEN, EVTQEN &
> > SMMUEN are all cleared, getting a Gerror should be treated as spurious
> >
> > That said, I understand your concerns about a real IRQ being interpreted
> > as a spurious one, and creating an IRQ storm since the gerror register
> > isn't really written. I have 2 ideas here:
> >
> > 1. We could have a "suspended" flag and check it with can_elide here:
> > arm_smmu_cmdq_can_elide() && is_suspended() to correctly return IRQ_NONE
> >
> > 2. We could explicitly disable Gerror in IRQ_CTRL write after setting
> > the CMDQ_STOP_FLAG. Even if there are Gerrors during the CMDQ drain,
> > we'll catcup to those at the end of our suspend callback.
> >
> > I'm more inclined towards 2 as it prevents potential races (execution of
> > an IRQ handler with handle_gerror calls at the end of the suspend).
> >
> > WDYT?
>
> I'm not sure if I have a good suggestion here. Have you considered the
> following: Do not call arm_smmu_handle_gerror() from
> arm_smmu_runtime_suspend(). Instead, call disable_irq() at the end of
> the suspend handler (and enable_irq() at the beginning of the resume
> handler)?
I thought about using disable_irq(), but I think doing it at the
hardware level (IRQ_CTRL) is better.
By disabling in IRQ_CTRL and keeping the manual arm_smmu_handle_gerror()
call at the end of suspend, we ensure that we don't lose any gerror info
We catch and handle any errors that occurred during the drain/quiesce
phase right before the power-down.
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v5 0/4] Enable sysfs module symlink for more built-in drivers
From: Danilo Krummrich @ 2026-06-09 10:29 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Shashank Balaji, James Clark, Alexander Shishkin,
Greg Kroah-Hartman, Rafael J . Wysocki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Thierry Reding,
Jonathan Hunter, Rahul Bukte, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <1c8e441a-6b33-465a-88f9-9552f346ae18@arm.com>
On Tue Jun 9, 2026 at 11:08 AM CEST, Suzuki K Poulose wrote:
> On 08/06/2026 23:24, Danilo Krummrich wrote:
>> On Mon, 18 May 2026 19:19:56 +0900, Shashank Balaji wrote:
>>> [PATCH v5 0/4] Enable sysfs module symlink for more built-in drivers
>>
>> Applied, thanks!
>>
>> Branch: driver-core-testing
>> Tree: git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
>>
>> [1/4] soc/tegra: cbb: Move driver registration from pure_initcall to core_initcall
>> commit: cd6e95e7ab29
>> [2/4] kernel: param: initialize module_kset in a pure_initcall
>> commit: c82dfce47833
>> [3/4] coresight: pass THIS_MODULE implicitly through a macro
>> commit: efc22b3f89a3
>> [4/4] driver core: platform: set mod_name in driver registration
>> commit: a7a7dc5c46a0
>>
>> The patches will appear in the next linux-next integration (typically within 24
>> hours on weekdays).
>>
>> The patches are in the driver-core-testing branch and will be promoted to
>> driver-core-next after validation.
>
> Apologies, I missed your emails. I am fine with those, happy to fixup
> anything if the linux-next screams.
Thanks for confirming! I did a test merge with linux-next and an allmodconfig
arm64 build before picking it up, so it should be fine.
Thanks,
Danilo
^ permalink raw reply
* [PATCH 3/3] remoteproc: qcom_sysmon: abort stop on unacknowledged shutdown
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
In-Reply-To: <20260609102254.2671238-1-mukesh.ojha@oss.qualcomm.com>
When a DSP hangs, if a graceful shutdown is attempted during sysmon stop,
it times out but sysmon_stop() still returns 0. The stop subdevice loop
then continues and tears down the glink and ssr subdevices, which
unregisters and unmaps the memory regions attached to rpmsg device. If the
remote still has DMA in flight against those regions, the result is an
SMMU fault.
Fix sysmon_stop() to return -ETIMEDOUT when a shutdown mechanism was
tried but the remote did not acknowledge it. With the abort-on-first-
failure behaviour already in rproc_stop_subdevices(), this prevents
glink and ssr from running their stop callbacks against an unresponsive
remote.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/remoteproc/qcom_sysmon.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index 44b905a7e129..a29084cf7145 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -559,6 +559,11 @@ static int sysmon_stop(struct rproc_subdev *subdev, bool crashed)
sysmon->shutdown_acked = ssctl_request_shutdown(sysmon);
else if (sysmon->ept)
sysmon->shutdown_acked = sysmon_request_shutdown(sysmon);
+ else
+ return 0;
+
+ if (!sysmon->shutdown_acked)
+ return -ETIMEDOUT;
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] remoteproc: abort subdev stop sequence on first failure
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
In-Reply-To: <20260609102254.2671238-1-mukesh.ojha@oss.qualcomm.com>
If a subdevice fails to stop, it indicates broken communication with the
DSP. Continuing to stop further subdevices against an unresponsive
remote processor could close rpmsg devices that could remove the memory
mapping from HLOS and in case if remote processor touches those memory
can result in SMMU fault.
Change rproc_stop_subdevices() to return int and abort on the first
failing subdev. Propagate the error through rproc_stop() and
__rproc_detach() so callers are aware the teardown did not complete
cleanly.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/remoteproc/remoteproc_core.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 21127d972bff..77c4f09c7604 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1110,7 +1110,7 @@ static int rproc_start_subdevices(struct rproc *rproc)
return ret;
}
-static void rproc_stop_subdevices(struct rproc *rproc, bool crashed)
+static int rproc_stop_subdevices(struct rproc *rproc, bool crashed)
{
struct rproc_subdev *subdev;
int ret;
@@ -1118,10 +1118,14 @@ static void rproc_stop_subdevices(struct rproc *rproc, bool crashed)
list_for_each_entry_reverse(subdev, &rproc->subdevs, node) {
if (subdev->stop) {
ret = subdev->stop(subdev, crashed);
- if (ret)
- dev_warn(&rproc->dev, "subdev stop failed: %d\n", ret);
+ if (ret) {
+ dev_err(&rproc->dev, "subdev stop failed: %d\n", ret);
+ return ret;
+ }
}
}
+
+ return 0;
}
static void rproc_unprepare_subdevices(struct rproc *rproc)
@@ -1712,7 +1716,12 @@ static int rproc_stop(struct rproc *rproc, bool crashed)
return -EINVAL;
/* Stop any subdevices for the remote processor */
- rproc_stop_subdevices(rproc, crashed);
+ ret = rproc_stop_subdevices(rproc, crashed);
+ if (ret) {
+ dev_err(dev, "failed to stop subdevices for %s: %d\n",
+ rproc->name, ret);
+ return ret;
+ }
/* the installed resource table is no longer accessible */
ret = rproc_reset_rsc_table_on_stop(rproc);
@@ -1751,7 +1760,12 @@ static int __rproc_detach(struct rproc *rproc)
return -EINVAL;
/* Stop any subdevices for the remote processor */
- rproc_stop_subdevices(rproc, false);
+ ret = rproc_stop_subdevices(rproc, false);
+ if (ret) {
+ dev_err(dev, "failed to stop subdevices for %s: %d\n",
+ rproc->name, ret);
+ return ret;
+ }
/* the installed resource table is no longer accessible */
ret = rproc_reset_rsc_table_on_detach(rproc);
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] remoteproc: check return value of subdev stop and unprepare callbacks
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
In-Reply-To: <20260609102254.2671238-1-mukesh.ojha@oss.qualcomm.com>
The stop() and unprepare() callbacks in struct rproc_subdev were void,
making it impossible for implementations to report failures. Unlike
prepare() and start() which already return int and have their errors
checked, errors during teardown were silently discarded.
Change the callback signatures to return int. Update
rproc_stop_subdevices() and rproc_unprepare_subdevices() to check each
return value and emit a warning on failure while continuing to visit all
remaining subdevices (best-effort teardown).
rproc_vdev_do_stop() propagates the error from device_for_each_child()
which it was already computing but had no way to surface. All other
implementations (glink, smd, ssr, pdm, sysmon) gain a return 0 as they
have no failure paths.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/remoteproc/qcom_common.c | 26 +++++++++++++++++++-------
drivers/remoteproc/qcom_sysmon.c | 10 +++++++---
drivers/remoteproc/remoteproc_core.c | 16 ++++++++++++----
drivers/remoteproc/remoteproc_virtio.c | 4 +++-
drivers/rpmsg/mtk_rpmsg.c | 8 ++++++--
include/linux/remoteproc.h | 4 ++--
6 files changed, 49 insertions(+), 19 deletions(-)
diff --git a/drivers/remoteproc/qcom_common.c b/drivers/remoteproc/qcom_common.c
index fd2b6824ad26..05a599318763 100644
--- a/drivers/remoteproc/qcom_common.c
+++ b/drivers/remoteproc/qcom_common.c
@@ -216,19 +216,23 @@ static int glink_subdev_start(struct rproc_subdev *subdev)
return PTR_ERR_OR_ZERO(glink->edge);
}
-static void glink_subdev_stop(struct rproc_subdev *subdev, bool crashed)
+static int glink_subdev_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_rproc_glink *glink = to_glink_subdev(subdev);
qcom_glink_smem_unregister(glink->edge);
glink->edge = NULL;
+
+ return 0;
}
-static void glink_subdev_unprepare(struct rproc_subdev *subdev)
+static int glink_subdev_unprepare(struct rproc_subdev *subdev)
{
struct qcom_rproc_glink *glink = to_glink_subdev(subdev);
qcom_glink_ssr_notify(glink->ssr_name);
+
+ return 0;
}
/**
@@ -327,12 +331,14 @@ static int smd_subdev_start(struct rproc_subdev *subdev)
return PTR_ERR_OR_ZERO(smd->edge);
}
-static void smd_subdev_stop(struct rproc_subdev *subdev, bool crashed)
+static int smd_subdev_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_rproc_subdev *smd = to_smd_subdev(subdev);
qcom_smd_unregister_edge(smd->edge);
smd->edge = NULL;
+
+ return 0;
}
/**
@@ -465,7 +471,7 @@ static int ssr_notify_start(struct rproc_subdev *subdev)
return 0;
}
-static void ssr_notify_stop(struct rproc_subdev *subdev, bool crashed)
+static int ssr_notify_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
struct qcom_ssr_notify_data data = {
@@ -475,9 +481,11 @@ static void ssr_notify_stop(struct rproc_subdev *subdev, bool crashed)
srcu_notifier_call_chain(&ssr->info->notifier_list,
QCOM_SSR_BEFORE_SHUTDOWN, &data);
+
+ return 0;
}
-static void ssr_notify_unprepare(struct rproc_subdev *subdev)
+static int ssr_notify_unprepare(struct rproc_subdev *subdev)
{
struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
struct qcom_ssr_notify_data data = {
@@ -487,6 +495,8 @@ static void ssr_notify_unprepare(struct rproc_subdev *subdev)
srcu_notifier_call_chain(&ssr->info->notifier_list,
QCOM_SSR_AFTER_SHUTDOWN, &data);
+
+ return 0;
}
/**
@@ -572,16 +582,18 @@ static int pdm_notify_prepare(struct rproc_subdev *subdev)
}
-static void pdm_notify_unprepare(struct rproc_subdev *subdev)
+static int pdm_notify_unprepare(struct rproc_subdev *subdev)
{
struct qcom_rproc_pdm *pdm = to_pdm_subdev(subdev);
if (!pdm->adev)
- return;
+ return 0;
auxiliary_device_delete(pdm->adev);
auxiliary_device_uninit(pdm->adev);
pdm->adev = NULL;
+
+ return 0;
}
/**
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index 913e3b750a86..44b905a7e129 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -531,7 +531,7 @@ static int sysmon_start(struct rproc_subdev *subdev)
return 0;
}
-static void sysmon_stop(struct rproc_subdev *subdev, bool crashed)
+static int sysmon_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_sysmon *sysmon = container_of(subdev, struct qcom_sysmon, subdev);
struct sysmon_event event = {
@@ -548,7 +548,7 @@ static void sysmon_stop(struct rproc_subdev *subdev, bool crashed)
/* Don't request graceful shutdown if we've crashed */
if (crashed)
- return;
+ return 0;
if (sysmon->ssctl_instance) {
if (!wait_for_completion_timeout(&sysmon->ssctl_comp, HZ / 2))
@@ -559,9 +559,11 @@ static void sysmon_stop(struct rproc_subdev *subdev, bool crashed)
sysmon->shutdown_acked = ssctl_request_shutdown(sysmon);
else if (sysmon->ept)
sysmon->shutdown_acked = sysmon_request_shutdown(sysmon);
+
+ return 0;
}
-static void sysmon_unprepare(struct rproc_subdev *subdev)
+static int sysmon_unprepare(struct rproc_subdev *subdev)
{
struct qcom_sysmon *sysmon = container_of(subdev, struct qcom_sysmon,
subdev);
@@ -574,6 +576,8 @@ static void sysmon_unprepare(struct rproc_subdev *subdev)
sysmon->state = SSCTL_SSR_EVENT_AFTER_SHUTDOWN;
blocking_notifier_call_chain(&sysmon_notifiers, 0, (void *)&event);
mutex_unlock(&sysmon->state_lock);
+
+ return 0;
}
/**
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index f003be006b1b..21127d972bff 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1113,20 +1113,28 @@ static int rproc_start_subdevices(struct rproc *rproc)
static void rproc_stop_subdevices(struct rproc *rproc, bool crashed)
{
struct rproc_subdev *subdev;
+ int ret;
list_for_each_entry_reverse(subdev, &rproc->subdevs, node) {
- if (subdev->stop)
- subdev->stop(subdev, crashed);
+ if (subdev->stop) {
+ ret = subdev->stop(subdev, crashed);
+ if (ret)
+ dev_warn(&rproc->dev, "subdev stop failed: %d\n", ret);
+ }
}
}
static void rproc_unprepare_subdevices(struct rproc *rproc)
{
struct rproc_subdev *subdev;
+ int ret;
list_for_each_entry_reverse(subdev, &rproc->subdevs, node) {
- if (subdev->unprepare)
- subdev->unprepare(subdev);
+ if (subdev->unprepare) {
+ ret = subdev->unprepare(subdev);
+ if (ret)
+ dev_warn(&rproc->dev, "subdev unprepare failed: %d\n", ret);
+ }
}
}
diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index d5e9ff045a28..128d3088a959 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -480,7 +480,7 @@ static int rproc_vdev_do_start(struct rproc_subdev *subdev)
return rproc_add_virtio_dev(rvdev, rvdev->id);
}
-static void rproc_vdev_do_stop(struct rproc_subdev *subdev, bool crashed)
+static int rproc_vdev_do_stop(struct rproc_subdev *subdev, bool crashed)
{
struct rproc_vdev *rvdev = container_of(subdev, struct rproc_vdev, subdev);
struct device *dev = &rvdev->pdev->dev;
@@ -489,6 +489,8 @@ static void rproc_vdev_do_stop(struct rproc_subdev *subdev, bool crashed)
ret = device_for_each_child(dev, NULL, rproc_remove_virtio_dev);
if (ret)
dev_warn(dev, "can't remove vdev child device: %d\n", ret);
+
+ return ret;
}
static int rproc_virtio_probe(struct platform_device *pdev)
diff --git a/drivers/rpmsg/mtk_rpmsg.c b/drivers/rpmsg/mtk_rpmsg.c
index 1b670ed54cfa..d8ea77055f31 100644
--- a/drivers/rpmsg/mtk_rpmsg.c
+++ b/drivers/rpmsg/mtk_rpmsg.c
@@ -326,7 +326,7 @@ static int mtk_rpmsg_prepare(struct rproc_subdev *subdev)
return 0;
}
-static void mtk_rpmsg_unprepare(struct rproc_subdev *subdev)
+static int mtk_rpmsg_unprepare(struct rproc_subdev *subdev)
{
struct mtk_rpmsg_rproc_subdev *mtk_subdev = to_mtk_subdev(subdev);
@@ -334,9 +334,11 @@ static void mtk_rpmsg_unprepare(struct rproc_subdev *subdev)
mtk_rpmsg_destroy_ept(mtk_subdev->ns_ept);
mtk_subdev->ns_ept = NULL;
}
+
+ return 0;
}
-static void mtk_rpmsg_stop(struct rproc_subdev *subdev, bool crashed)
+static int mtk_rpmsg_stop(struct rproc_subdev *subdev, bool crashed)
{
struct mtk_rpmsg_channel_info *info, *next;
struct mtk_rpmsg_rproc_subdev *mtk_subdev = to_mtk_subdev(subdev);
@@ -372,6 +374,8 @@ static void mtk_rpmsg_stop(struct rproc_subdev *subdev, bool crashed)
kfree(info);
}
mutex_unlock(&mtk_subdev->channels_lock);
+
+ return 0;
}
struct rproc_subdev *
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 7c1546d48008..315c479d163a 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -335,8 +335,8 @@ struct rproc_subdev {
int (*prepare)(struct rproc_subdev *subdev);
int (*start)(struct rproc_subdev *subdev);
- void (*stop)(struct rproc_subdev *subdev, bool crashed);
- void (*unprepare)(struct rproc_subdev *subdev);
+ int (*stop)(struct rproc_subdev *subdev, bool crashed);
+ int (*unprepare)(struct rproc_subdev *subdev);
};
/* we currently support only two vrings per rvdev */
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] remoteproc: fix silent teardown failures and prevent SMMU faults on hung DSP
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
When a DSP hangs without triggering its own crash handler, a graceful
shutdown via sysmon times out. Before this series, two things went
wrong:
1. The stop() and unprepare() callbacks in struct rproc_subdev were
void. Implementations had no way to surface failures, and callers
discarded any internal error state silently.
2. Even if an error had been detectable, rproc_stop_subdevices() kept
iterating after a failed stop. This meant glink and ssr subdevices
were torn down regardless, causing HLOS to unregister and unmap the
shared memory regions. If the remote still had DMA in flight
against those regions — as is often the case with a hung DSP — the
result was an SMMU fault.
This series fixes both problems in three steps.
Patch 1 changes stop() and unprepare() from void to int, matching
prepare() and start(). Most implementations gain a trivial return 0;
rproc_vdev_do_stop() now surfaces the error it was already computing.
Callers warn on failure but continue iterating (best-effort).
Patch 2 changes rproc_stop_subdevices() to abort and return error on the
first failing subdev, propagating through rproc_stop() and
__rproc_detach().
Patch 3 makes sysmon_stop() return -ETIMEDOUT when the remote does not
acknowledge a graceful shutdown request. Combined with patch 2, this
prevents glink and ssr from unmapping shared memory against a hung DSP.
Mukesh Ojha (3):
remoteproc: check return value of subdev stop and unprepare callbacks
remoteproc: abort subdev stop sequence on first failure
remoteproc: qcom_sysmon: abort stop on unacknowledged shutdown
drivers/remoteproc/qcom_common.c | 26 ++++++++++++++-----
drivers/remoteproc/qcom_sysmon.c | 15 ++++++++---
drivers/remoteproc/remoteproc_core.c | 36 +++++++++++++++++++++-----
drivers/remoteproc/remoteproc_virtio.c | 4 ++-
drivers/rpmsg/mtk_rpmsg.c | 8 ++++--
include/linux/remoteproc.h | 4 +--
6 files changed, 71 insertions(+), 22 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH 4/4] arm64: route crash_smp_send_stop() last resort through SDEI
From: Kiryl Shutsemau @ 2026-06-09 10:21 UTC (permalink / raw)
To: Doug Anderson
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <aiNCk2M0OlD7VaEs@thinkstation>
On Fri, Jun 05, 2026 at 10:46:11PM +0100, Kiryl Shutsemau wrote:
> On Fri, Jun 05, 2026 at 01:42:57PM -0700, Doug Anderson wrote:
> > > + sdei_nmi_crash_smp_send_stop();
> >
> > It feels weird to me that you're adding SDEI for "crash stop" but not
> > for regular "stop". It feels like you should modify smp_send_stop() to
> > fall back to SDEI if sending the NMI failed, instead of adding this
> > separate path.
>
> Fair. A wedged CPU ignores the reboot-path stop just the same, and the
> escalation logic already lives in smp.c, so I'll restructure in v2.
>
> One thing to sort out there: this patch parks the stopped CPU inside
> its SDEI handler without completing the event, which is fine for the
> crash case (nothing expects the CPU back before reset), but a generic
> stop path probably wants SDEI_EVENT_COMPLETE_AND_RESUME into a parking
> stub instead, so that e.g. a regular kexec can bring all CPUs back up
> in the new kernel. I'll look into that as part of the rework.
Regular kexec takes different path and offlines CPU normally. So the
next kernel can start them. But crash kernel cannot re-use wedged CPU.
C&R alone doesn't buy us anything. We need to get the CPU to CPU_OFF.
I am trying to do this, but so far no luck. Crash kernel fails to start
at all if try to do C&R and then CPU_OFF. C&R alone works, but CPU is
still unreachable by the next kernel, as expected.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v3 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE
From: Marc Zyngier @ 2026-06-09 10:21 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber,
"Yu-Chun Lin [林祐君]", Heiko Stuebner,
Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <ea15cce1-b393-43f6-8d58-3d6f90f0c0cd@samsung.com>
On Tue, 09 Jun 2026 11:03:21 +0100,
Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Dear All,
>
> On 23.05.2026 16:02, Marc Zyngier wrote:
> > When running with at EL2 with VHE enabled, the architecture provides
> > two EL2 timer/counters, dubbed physical and virtual. Apart from their
> > names, they are strictly identical.
> >
> > However, they don't get virtualised the same way, specially when
> > it comes to adding arbitrary offsets to the timers. When running as
> > a guest, the host CNTVOFF_EL2 does apply to the guest's view of
> > CNTHV*_El2. This is not true for CNTPOFF_EL2 and CNTHP*_EL2, as
> > the architecture is broken past the first level of virtualisation
> > (it lacks some essential mechanisms to be usable, despite what
> > the ARM ARM pretends).
> >
> > This means that when running as a L2 guest hypervisor, using the
> > physical timer results in traps to L0, which are then forwarded to
> > L1 in order to emulate the offset, leading to even worse performance
> > due to massive trap amplification (the combination of register and
> > ERET trapping is absolutely lethal).
> >
> > Switch the arch timer code to using the virtual timer when running
> > in VHE by default, only using the physical timer if the interrupt
> > is not correctly described in the firmware tables (which seems
> > to be an unfortunately common case). This comes as no impact on
> > bare-metal, and slightly improves the situation in the virtualised
> > case.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> This patch landed recently in linux-next as commit d87773de9efe
> ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when
> running VHE"). In my tests I found that it breaks booting of RaspberryPi5
> board. Reverting it on top of linux-next fixes the issue. Here is a boot
> log:
Huh.
[...]
> arch_timer: cp15 timer running at 54.00MHz (hyp-virt).
> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
> sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
The interrupt appears to be advertised in the DT, but doesn't seem to
fire. That's obviously not going to end well. My suspicion is that
either the interrupt isn't wired (that'd be hilariously abd), or is
left as Group-0 by the firmware (copy-paste from RPi4).
Can you try the following hack and let me know if the kernel shouts at
you?
Thanks,
M.
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index ec70c84e9f91d..d05791e6cc0db 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -213,6 +213,7 @@ static void gic_eoimode1_mask_irq(struct irq_data *d)
static void gic_unmask_irq(struct irq_data *d)
{
gic_poke_irq(d, GIC_DIST_ENABLE_SET);
+ WARN_ON(!gic_peek_irq(d, GIC_DIST_ENABLE_SET));
}
static void gic_eoi_irq(struct irq_data *d)
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH v8 09/12] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops
From: Pranjal Shrivastava @ 2026-06-09 10:13 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rCTHZOiSx5tTVmLmubJ4SUDtXvCX6oLqsdEsPAFTKJZ4A@mail.gmail.com>
On Tue, Jun 02, 2026 at 08:27:22AM -0700, Daniel Mentz wrote:
> On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> > +static inline u32 arm_smmu_cmdq_owner_prod_idx(struct arm_smmu_cmdq *cmdq)
> > +{
> > + return atomic_read(&cmdq->owner_prod) & CMDQ_PROD_IDX_MASK;
>
> Is this masking necessary? Can't we just use
> atomic_read(&cmdq->owner_prod) as is? The only place in
> arm_smmu_cmdq_issue_cmdlist() that writes to cmdq->owner_prod already
> applied CMDQ_PROD_IDX_MASK.
Ack. I'll drop the masking.
>
> > +}
> > +
>
> > @@ -4839,6 +4876,10 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
> > return ret;
> > }
> >
> > + /* Clear any flags from the previous life */
> > + atomic_andnot(CMDQ_PROD_STOP_FLAG, &smmu->cmdq.owner_prod);
>
> Same. I believe CMDQ_PROD_STOP_FLAG will never be set in
> smmu->cmdq.owner_prod. Hence, clearing it shouldn't be necessary.
Ack. I'll drop this.
>
> > + atomic_andnot(CMDQ_PROD_STOP_FLAG, &smmu->cmdq.q.llq.atomic.prod);
> > +
> > /* Invalidate any cached configuration */
> > arm_smmu_cmdq_issue_cmd_with_sync(smmu, arm_smmu_make_cmd_cfgi_all());
> >
> > @@ -4898,6 +4939,21 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
Thanks,
Praan
^ permalink raw reply
* [PATCH 2/3] arm64: cputype: Add C1-Premium definitions
From: Mark Rutland @ 2026-06-09 10:12 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: catalin.marinas, mark.rutland, will
In-Reply-To: <20260609101203.1512409-1-mark.rutland@arm.com>
Add cputype definitions for C1-Premium. These will be used for errata
detection in subsequent patches.
These values can be found in the C1-Premium TRM:
https://developer.arm.com/documentation/109416/0100/
... in section A.5.1 ("MIDR_EL1, Main ID Register").
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 3e223a7781866..1b9f0cda1336d 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -100,6 +100,7 @@
#define ARM_CPU_PART_C1_ULTRA 0xD8C
#define ARM_CPU_PART_NEOVERSE_N3 0xD8E
#define ARM_CPU_PART_C1_PRO 0xD8B
+#define ARM_CPU_PART_C1_PREMIUM 0xD90
#define APM_CPU_PART_XGENE 0x000
#define APM_CPU_VAR_POTENZA 0x00
@@ -193,6 +194,7 @@
#define MIDR_C1_ULTRA MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_ULTRA)
#define MIDR_NEOVERSE_N3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N3)
#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PRO)
+#define MIDR_C1_PREMIUM MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PREMIUM)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
--
2.30.2
^ permalink raw reply related
* [PATCH 3/3] arm64: errata: Mitigate TLBI errata on various Arm CPUs
From: Mark Rutland @ 2026-06-09 10:12 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: catalin.marinas, mark.rutland, will
In-Reply-To: <20260609101203.1512409-1-mark.rutland@arm.com>
A number of CPUs developed by Arm suffer from errata whereby a broadcast
TLBI;DSB sequence may complete before the global observation of writes
which are translated by an affected TLB entry.
These errata ONLY affect the completion of memory accesses which have
been translated by an invalidated TLB entry, and these errata DO NOT
affect the actual invalidation of TLB entries. TLB entries are removed
correctly.
This issue has been assigned CVE ID CVE-2025-10263.
To mitigate this issue, Arm recommends that software follows any
affected TLBI;DSB sequence with an additional TLBI;DSB, which will
ensure that all memory write effects affected by the first TLBI have
been globally observed. The additional TLBI can use any operation that
is broadcast to affected CPUs, and the additional DSB can use any option
that is sufficient to complete the additional TLBI.
The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate
the issue. Enable this workaround for affected CPUs, and update the
silicon errata documentation accordingly.
Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
Documentation/arch/arm64/silicon-errata.rst | 42 +++++++++++++++++++++
arch/arm64/Kconfig | 36 ++++++++++++++++++
arch/arm64/kernel/cpu_errata.c | 32 +++++++++++++++-
3 files changed, 108 insertions(+), 2 deletions(-)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 61c2fd7ef6441..6f4a93602abca 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -129,17 +129,29 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #4193800 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76AE | #4193801 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1491015 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A77 | #4193798 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A78 | #4193791 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A78AE | #4193793 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78C | #3324346, | ARM64_ERRATUM_3194386 |
| | | #3324347 | |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A78C | #4193794 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
@@ -148,6 +160,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #3324338 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #4193788 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 |
@@ -160,20 +174,32 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X1 | #4193791 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X1C | #4193792 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #3324338 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #4193788 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X3 | #3324335 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X3 | #4193786 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X4 | #4118414 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X925 | #3324334 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X925 | #4193781 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1188873, | ARM64_ERRATUM_1418040 |
| | | #1418040 | |
+----------------+-----------------+-----------------+-----------------------------+
@@ -184,6 +210,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #4193800 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
@@ -192,20 +220,34 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #4193789 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V1 | #1619801 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V1 | #4193790 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V2 | #4193787 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V3 | #4193784 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V3AE | #4193784 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | C1-Premium | #4193780 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | C1-Pro | #4193714 | ARM64_ERRATUM_4193714 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | C1-Ultra | #4193780 | ARM64_ERRATUM_4118414 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-500 | #562869, | ARM_SMMU_MMU_500_CPRE_ERRATA|
| | | #841119, | |
| | | #826419, | |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 62fe27f2f6981..8065b733aa8c6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1154,6 +1154,42 @@ config ARM64_ERRATUM_4193714
If unsure, say Y.
+config ARM64_ERRATUM_4118414
+ bool "Cortex-*/Neoverse-*/C1-*: Completion of affected memory accesses might not be guaranteed by completion of a TLBI"
+ default y
+ select ARM64_WORKAROUND_REPEAT_TLBI
+ help
+ This option adds a workaround for the following errata:
+
+ * ARM C1-Premium erratum 4193780
+ * ARM C1-Ultra erratum 4193780
+ * ARM Cortex-A76 erratum 4193800
+ * ARM Cortex-A76AE erratum 4193801
+ * ARM Cortex-A77 erratum 4193798
+ * ARM Cortex-A78 erratum 4193791
+ * ARM Cortex-A78AE erratum 4193793
+ * ARM Cortex-A78C erratum 4193794
+ * ARM Cortex-A710 erratum 4193788
+ * ARM Cortex-X1 erratum 4193791
+ * ARM Cortex-X1C erratum 4193792
+ * ARM Cortex-X2 erratum 4193788
+ * ARM Cortex-X3 erratum 4193786
+ * ARM Cortex-X4 erratum 4118414
+ * ARM Cortex-X925 erratum 4193781
+ * ARM Neoverse-N1 erratum 4193800
+ * ARM Neoverse-N2 erratum 4193789
+ * ARM Neoverse-V1 erratum 4193790
+ * ARM Neoverse-V2 erratum 4193787
+ * ARM Neoverse-V3 erratum 4193784
+ * ARM Neoverse-V3AE erratum 4193784
+
+ On affected cores, some memory accesses might not be completed by
+ broadcast TLB invalidation.
+
+ This issue is also known as CVE-2025-10263.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 310e6f120992d..95e3be145fb1e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -340,7 +340,35 @@ static const struct arm64_cpu_capabilities arm64_repeat_tlbi_list[] = {
ERRATA_MIDR_RANGE(MIDR_CORTEX_A510, 0, 0, 1, 1),
},
#endif
- {},
+#ifdef CONFIG_ARM64_ERRATUM_4118414
+ {
+ ERRATA_MIDR_RANGE_LIST(((const struct midr_range[]) {
+ MIDR_ALL_VERSIONS(MIDR_C1_PREMIUM),
+ MIDR_ALL_VERSIONS(MIDR_C1_ULTRA),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A76AE),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A77),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A78),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A78AE),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A78C),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A710),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X1),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X1C),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X2),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X3),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X4),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X925),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V2),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3AE),
+ {}
+ })),
+ },
+#endif
+ {}
};
#endif
@@ -705,7 +733,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
#endif
#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
{
- .desc = "Qualcomm erratum 1009, or ARM erratum 1286807, 2441009",
+ .desc = "Broken broadcast TLBI completion",
.capability = ARM64_WORKAROUND_REPEAT_TLBI,
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
.matches = cpucap_multi_entry_cap_matches,
--
2.30.2
^ permalink raw reply related
* [PATCH 1/3] arm64: cputype: Add C1-Ultra definitions
From: Mark Rutland @ 2026-06-09 10:12 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: catalin.marinas, mark.rutland, will
In-Reply-To: <20260609101203.1512409-1-mark.rutland@arm.com>
Add cputype definitions for C1-Ultra. These will be used for errata
detection in subsequent patches.
These values can be found in the C1-Ultra TRM:
https://developer.arm.com/documentation/108014/0100/
... in section A.5.1 ("MIDR_EL1, Main ID Register").
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 7b518e81dd15b..3e223a7781866 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -97,6 +97,7 @@
#define ARM_CPU_PART_CORTEX_X925 0xD85
#define ARM_CPU_PART_CORTEX_A725 0xD87
#define ARM_CPU_PART_CORTEX_A720AE 0xD89
+#define ARM_CPU_PART_C1_ULTRA 0xD8C
#define ARM_CPU_PART_NEOVERSE_N3 0xD8E
#define ARM_CPU_PART_C1_PRO 0xD8B
@@ -189,6 +190,7 @@
#define MIDR_CORTEX_X925 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X925)
#define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)
#define MIDR_CORTEX_A720AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720AE)
+#define MIDR_C1_ULTRA MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_ULTRA)
#define MIDR_NEOVERSE_N3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N3)
#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PRO)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
--
2.30.2
^ permalink raw reply related
* [PATCH 0/3] arm64: errata: Mitigate TLBI errata on various Arm CPUs
From: Mark Rutland @ 2026-06-09 10:12 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: catalin.marinas, mark.rutland, will
A number of CPUs developed by Arm suffer from errata whereby a broadcast
TLBI;DSB sequence may complete before the global observation of writes
which are translated by an affected TLB entry.
The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate
the issue. This series enables the workaround on affected parts,
requiring the addition of MIDR values for C1-Ultra and C1-Premium.
I've based the series on the arm64 for-next/core branch to avoid
conflicts with the recent formatting changes to
Documentation/arch/arm64/silicon-errata.rst.
This issue has been assigned CVE ID CVE-2025-10263, and Arm have
published a security bulletin:
https://developer.arm.com/documentation/112137/latest/
This will require manual backporting, so I haven't CC'd stable
explicitly. Once this is queueud I'll push out branches with backports
to the active stable trees.
Thanks,
Mark.
Mark Rutland (3):
arm64: cputype: Add C1-Ultra definitions
arm64: cputype: Add C1-Premium definitions
arm64: errata: Mitigate TLBI errata on various Arm CPUs
Documentation/arch/arm64/silicon-errata.rst | 42 +++++++++++++++++++++
arch/arm64/Kconfig | 36 ++++++++++++++++++
arch/arm64/include/asm/cputype.h | 4 ++
arch/arm64/kernel/cpu_errata.c | 32 +++++++++++++++-
4 files changed, 112 insertions(+), 2 deletions(-)
--
2.30.2
^ permalink raw reply
* Re: [PATCH v8 09/12] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops
From: Pranjal Shrivastava @ 2026-06-09 10:12 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rDjFwacP0_TA8tv5_p7ZJejsXAKEb=juNaXgPcMPag+Eg@mail.gmail.com>
On Sun, Jun 07, 2026 at 02:53:24PM -0700, Daniel Mentz wrote:
> On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> > @@ -4898,6 +4939,21 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
> > if (is_kdump_kernel())
> > enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
> >
> > + /*
> > + * While the SMMU was suspended, concurrent CPU threads may have
> > + * updated in-memory structures (such as STEs, CDs, and PTEs).
> > + * Any invalidations corresponding to those updates were safely
> > + * elided because the command queue was stopped (STOP_FLAG == 1).
> > + *
> > + * Since the reset invalidate-all commands above have fully cleared
> > + * the HW TLBs and config caches, the SMMU will fetch these descriptors
> > + * directly from RAM as soon as translation is enabled.
> > + *
> > + * Add a memory barrier to collect all prior RAM writes to ensure the
> > + * SMMU sees a consistent view of memory before translation is enabled.
> > + */
> > + smp_mb();
>
> I'm not convinced that this is necessary. I understand that the write
> to smmu->cmdq.q.llq.atomic.prod needs to be ordered before setting
> CR0_SMMUEN in ARM_SMMU_CR0. However, this ordering requirement appears
> to already be met by the dma_wmb() in arm_smmu_cmdq_issue_cmdlist.
> Could you provide an example of a scenario that might fail if this
> smp_mb() were removed?
Agreed. The first dma_wmb() in the issue_cmdlist will handle this. We
don't need this smp_mb(); I'll add a note as specified in [1]
Thanks,
Praan
[1] https://lore.kernel.org/all/aiflaI4svEJvZbsC@google.com/
^ permalink raw reply
* Re: [PATCH 23/37] drm/encoder: add drm_encoder_cleanup_from()
From: Luca Ceresoli @ 2026-06-09 10:10 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260608-mighty-woodlouse-of-reading-162bca@houat>
On Mon Jun 8, 2026 at 2:10 PM CEST, Maxime Ripard wrote:
> On Tue, May 19, 2026 at 12:37:40PM +0200, Luca Ceresoli wrote:
>> Supporting hardware whose final part of the DRM pipeline can be physically
>> removed requires the ability to detach all bridges from a given point to
>> the end of the pipeline.
>>
>> Introduce a variant of drm_encoder_cleanup() for this.
>>
>> Take care to not try detaching non-attached bridges. This is needed because
>> when two or more bridges are removed not in the backwards order,
>> drm_encoder_cleanup_from() is called more than once for bridges closer to
>> the panel.
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>
>> ---
>>
>> Note: in theory drm_encoder_cleanup() is now a superset of
>> drm_encoder_cleanup_from() and may be simplified to just call
>> drm_encoder_cleanup_from() and then do the extra actions. However the
>> common code is subtly different in terms of locking and checks, so this
>> would complicate the code in this patch and has thus been kept separate for
>> the time being to make reviewing sompler. Reimplementing
>> drm_encoder_cleanup() by using drm_encoder_cleanup_from() cvacn be done
>> later on.
>>
>> A much simpler and now obsolete version of this patch (missing locking and
>> checks) previously appeared in
>> https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-13-9d6f2c9c3058@bootlin.com/
>> ---
>> drivers/gpu/drm/drm_encoder.c | 38 ++++++++++++++++++++++++++++++++++++++
>> include/drm/drm_encoder.h | 1 +
>> 2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
>> index 0d5dbed06db4..40ece477b302 100644
>> --- a/drivers/gpu/drm/drm_encoder.c
>> +++ b/drivers/gpu/drm/drm_encoder.c
>> @@ -179,6 +179,44 @@ int drm_encoder_init(struct drm_device *dev,
>> }
>> EXPORT_SYMBOL(drm_encoder_init);
>>
>> +/**
>> + * drm_encoder_cleanup_from - remove a given bridge and all the following
>> + * @encoder: encoder whole list of bridges shall be pruned
>> + * @bridge: first bridge to remove
>> + *
>> + * Removes from an encoder all the bridges starting with a given bridge
>> + * and until the end of the chain.
>> + *
>> + * Does nothing if the bridge is not attached to an encoder chain.
>> + *
>> + * This should not be used in "normal" DRM pipelines. It is only useful for
>> + * devices whose final part of the DRM chain can be physically removed and
>> + * later reconnected (possibly with different hardware).
>> + */
>> +void drm_encoder_cleanup_from(struct drm_encoder *encoder, struct drm_bridge *bridge)
>> +{
>> + struct drm_bridge *next;
>> + LIST_HEAD(tmplist);
>> +
>> + /*
>> + * We need the bridge_chain_mutex to modify the chain, but
>> + * drm_bridge_detach() will call DRM_MODESET_LOCK_ALL_BEGIN() (in
>> + * drm_modeset_lock_fini()), resulting in a possible ABBA circular
>> + * deadlock. Avoid it by first moving all the bridges to a
>> + * temporary list holding the lock, and then calling
>> + * drm_bridge_detach() without the lock.
>> + */
>> + mutex_lock(&encoder->bridge_chain_mutex);
>> + if (!list_empty(&bridge->chain_node))
>> + list_for_each_entry_safe_from(bridge, next, &encoder->bridge_chain, chain_node)
>> + list_move_tail(&bridge->chain_node, &tmplist);
>> + mutex_unlock(&encoder->bridge_chain_mutex);
>> +
>> + while (!list_empty(&tmplist))
>> + drm_bridge_detach(list_first_entry(&tmplist, struct drm_bridge, chain_node));
>> +}
>> +EXPORT_SYMBOL(drm_encoder_cleanup_from);
>> +
>
> The name is super confusing, because it doesn't clean up anything.
> drm_encoder_cleanup is called that way because it cleans up the encoder.
> This function doesn't.
>
> Unlike what's being documented, it doesn't remove any bridge either. It
> just detaches bridge, so let's just call it that way?
Good point.
What about:
* rename to drm_bridge_detach_from()
* drop the @encoder argument (get if from bridge->encoder)
* maybe even move to drm_bridge.c?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v8 09/12] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops
From: Pranjal Shrivastava @ 2026-06-09 10:09 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rC4a55Hfg+JZZora4UYxJyz9WgUV_kqBt_ejUy+9RLzYQ@mail.gmail.com>
On Sun, Jun 07, 2026 at 03:30:00PM -0700, Daniel Mentz wrote:
> On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> > +static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
> > +{
> > + struct arm_smmu_device *smmu = dev_get_drvdata(dev);
> > + struct arm_smmu_cmdq *cmdq = &smmu->cmdq;
> > + int timeout = ARM_SMMU_SUSPEND_TIMEOUT_US;
> > + u32 enables, target;
> > + int ret;
> > +
> > + /* Abort all transactions before disable to avoid spurious bypass */
> > + arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
> > +
> > + /* Disable the SMMU via CR0.EN and all queues except CMDQ */
> > + enables = CR0_CMDQEN;
> > + ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0, ARM_SMMU_CR0ACK);
> > + if (ret) {
> > + dev_err(smmu->dev, "failed to disable SMMU\n");
> > + return ret;
> > + }
> > +
> > + /*
> > + * At this point the SMMU is completely disabled and won't access
> > + * any translation/config structures, even speculative accesses
> > + * aren't performed as per the IHI0070 spec (section 6.3.9.6).
> > + */
> > +
> > + /* Mark the CMDQ to stop and get the target index before the stop */
> > + target = atomic_fetch_or_relaxed(CMDQ_PROD_STOP_FLAG, &cmdq->q.llq.atomic.prod);
>
> I'm wondering if we need the non-relaxed version of atomic_fetch_or()
> here to benefit from the barrier guarantees. Otherwise, how do you
> ensure that CMDQ_PROD_STOP_FLAG isn't set before SMMUEN is cleared?
Ack. I agree we need a non-relaxed version, I missed that the STOP_FLAG
is purely RAM & was focused on the _relaxed variants to keep things
ordered as all were MMIO. I'll drop the relaxed semantics with the
STOP_FLAG.
>
> > + target &= CMDQ_PROD_IDX_MASK;
Thanks,
Praan
^ permalink raw reply
* [soc:soc/dt] BUILD SUCCESS 7b93c5b05877bc5df662d4edd827936fa2d39fc4
From: kernel test robot @ 2026-06-09 10:07 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: 7b93c5b05877bc5df662d4edd827936fa2d39fc4 Merge tag 'socfpga_dts_updates_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into soc/dt
elapsed time: 6520m
configs tested: 85
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig gcc-16.1.0
arm allnoconfig clang-23
arm allyesconfig gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 randconfig-001-20260609 clang-23
arm64 randconfig-002-20260609 gcc-13.4.0
arm64 randconfig-003-20260609 gcc-15.2.0
arm64 randconfig-004-20260609 clang-23
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky randconfig-001-20260609 gcc-9.5.0
csky randconfig-002-20260609 gcc-11.5.0
hexagon allmodconfig clang-23
hexagon allnoconfig clang-23
hexagon randconfig-001-20260609 clang-18
hexagon randconfig-002-20260609 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-20
loongarch randconfig-001-20260609 clang-23
loongarch randconfig-002-20260609 clang-23
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 randconfig-001-20260609 gcc-11.5.0
nios2 randconfig-002-20260609 gcc-11.5.0
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig gcc-16.1.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv randconfig-002-20260609 clang-23
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 randconfig-001-20260609 clang-23
s390 randconfig-002-20260609 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig gcc-16.1.0
sh allyesconfig gcc-16.1.0
sh randconfig-001-20260609 gcc-13.4.0
sh randconfig-002-20260609 gcc-11.5.0
sparc allnoconfig gcc-16.1.0
sparc randconfig-001-20260609 gcc-16.1.0
sparc randconfig-002 gcc-11.5.0
sparc64 allmodconfig clang-20
sparc64 randconfig-001 gcc-12.5.0
um allmodconfig clang-23
um allnoconfig clang-16
um allyesconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-004-20260609 gcc-14
x86_64 buildonly-randconfig-006-20260609 gcc-14
x86_64 randconfig-001-20260609 gcc-14
x86_64 randconfig-002-20260609 clang-22
x86_64 randconfig-003-20260609 gcc-14
x86_64 randconfig-004-20260609 clang-22
x86_64 randconfig-005-20260609 clang-22
x86_64 randconfig-006-20260609 clang-22
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/2] soc: samsung: exynos-pmu: fix of_node refcount leak in exynos_get_pmu_regmap()
From: Krzysztof Kozlowski @ 2026-06-09 10:07 UTC (permalink / raw)
To: geoffrey
Cc: Alim Akhtar, Marek Szyprowski, Tomasz Figa, linux-arm-kernel,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260609095224.1706036-2-geoffreyhe2@gmail.com>
On 09/06/2026 11:52, geoffrey wrote:
> From: Weigang He <geoffreyhe2@gmail.com>
>
> exynos_get_pmu_regmap() obtains a device_node via of_find_matching_node()
> and passes it to exynos_get_pmu_regmap_by_phandle(np, NULL). With
> propname == NULL the callee uses np directly and only drops a reference
> when propname is set, so the reference taken by of_find_matching_node()
> is leaked on every call -- including on each -EPROBE_DEFER retry of the
> only in-tree caller, exynos_retention_init() in the Exynos pinctrl
> driver.
>
> Drop the reference in the function that acquired it.
>
> Found by static analysis tool CodeQL.
>
> Fixes: 76640b84bd7a ("soc: samsung: pmu: Provide global function to get PMU regmap")
> Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
> ---
> drivers/soc/samsung/exynos-pmu.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
> index d58376c38179b..a5da2741852b4 100644
> --- a/drivers/soc/samsung/exynos-pmu.c
> +++ b/drivers/soc/samsung/exynos-pmu.c
> @@ -167,11 +167,17 @@ static const struct mfd_cell exynos_pmu_devs[] = {
> */
> struct regmap *exynos_get_pmu_regmap(void)
> {
> - struct device_node *np = of_find_matching_node(NULL,
> - exynos_pmu_of_device_ids);
Use __free() to make it simpler.
>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 2/2] crypto: atmel-ecc - clean up and improve ECDH comments
From: Thorsten Blum @ 2026-06-09 10:05 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260609100552.233494-3-thorsten.blum@linux.dev>
Improve the kerneldoc for struct atmel_ecdh_ctx by removing the stale
"unsupported curves" wording, since the device only supports a single
curve (P-256), and move the set_secret() constraint to the description.
In atmel_ecdh_set_secret(), clarify that the device generates the
private key, and drop the redundant "only supports NIST P256" comment.
In atmel_ecdh_done() and atmel_ecdh_generate_public_key(), clarify the
truncation comments. Also note that a P-256 public key consists of two
32-byte coordinates in atmel_ecdh_compute_shared_secret(), and remove
the unnecessary fall-through comment and other redundant comments.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Adjust atmel_ecdh_ctx kerneldoc formatting/indentation according to:
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#members
- v1: https://lore.kernel.org/r/20260603192708.1237715-4-thorsten.blum@linux.dev/
---
drivers/crypto/atmel-ecc.c | 38 ++++++++++++++------------------------
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 0ca02995a1de..cd33d3f132cc 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -27,15 +27,14 @@ static struct atmel_ecc_driver_data driver_data;
/**
* struct atmel_ecdh_ctx - transformation context
- * @client : pointer to i2c client device
- * @fallback : used for unsupported curves or when user wants to use its own
- * private key.
- * @public_key : generated when calling set_secret(). It's the responsibility
- * of the user to not call set_secret() while
- * generate_public_key() or compute_shared_secret() are in flight.
- * @curve_id : elliptic curve id
- * @do_fallback: true when the device doesn't support the curve or when the user
- * wants to use its own private key.
+ * @client: I2C client device
+ * @fallback: ECDH fallback used for caller-provided private keys
+ * @public_key: cached public key for the device-generated private key
+ * @curve_id: elliptic curve id
+ * @do_fallback: true when ECDH operations should use @fallback
+ *
+ * The caller must not invoke set_secret() while generate_public_key()
+ * or compute_shared_secret() are in flight.
*/
struct atmel_ecdh_ctx {
struct i2c_client *client;
@@ -55,7 +54,7 @@ static void atmel_ecdh_done(struct atmel_i2c_work_data *work_data, void *areq,
if (status)
goto free_work_data;
- /* might want less than we've got */
+ /* copy only as much as requested, capped at 32 bytes */
n_sz = min(ATMEL_ECC_NIST_P256_N_SIZE, req->dst_len);
/* copy the shared secret */
@@ -64,15 +63,15 @@ static void atmel_ecdh_done(struct atmel_i2c_work_data *work_data, void *areq,
if (copied != n_sz)
status = -EINVAL;
- /* fall through */
free_work_data:
kfree_sensitive(work_data);
kpp_request_complete(req, status);
}
/*
- * A random private key is generated and stored in the device. The device
- * returns the pair public key.
+ * If no private key is provided, generate one in the device and cache
+ * the corresponding public key. The generated private key never leaves
+ * the device.
*/
static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
unsigned int len)
@@ -83,9 +82,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
struct ecdh params;
int ret = -ENOMEM;
- /* free the old public key, if any */
kfree(ctx->public_key);
- /* make sure you don't free the old public key twice */
ctx->public_key = NULL;
if (crypto_ecdh_decode_key(buf, len, ¶ms) < 0) {
@@ -94,7 +91,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
}
if (params.key_size) {
- /* fallback to ecdh software implementation */
ctx->do_fallback = true;
return crypto_kpp_set_secret(ctx->fallback, buf, len);
}
@@ -103,11 +99,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
if (!cmd)
return -ENOMEM;
- /*
- * The device only supports NIST P256 ECC keys. The public key size will
- * always be the same. Use a macro for the key size to avoid unnecessary
- * computations.
- */
public_key = kmalloc(ATMEL_ECC_PUBKEY_SIZE, GFP_KERNEL);
if (!public_key)
goto free_cmd;
@@ -120,7 +111,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
if (ret)
goto free_public_key;
- /* save the public key */
memcpy(public_key, &cmd->data[RSP_DATA_IDX], ATMEL_ECC_PUBKEY_SIZE);
ctx->public_key = public_key;
@@ -149,7 +139,7 @@ static int atmel_ecdh_generate_public_key(struct kpp_request *req)
if (!ctx->public_key)
return -EINVAL;
- /* might want less than we've got */
+ /* copy only as much as requested, capped at 64 bytes */
nbytes = min(ATMEL_ECC_PUBKEY_SIZE, req->dst_len);
/* public key was saved at private key generation */
@@ -175,7 +165,7 @@ static int atmel_ecdh_compute_shared_secret(struct kpp_request *req)
return crypto_kpp_compute_shared_secret(req);
}
- /* must have exactly two points to be on the curve */
+ /* A P-256 public key must contain two 32-byte coordinates */
if (req->src_len != ATMEL_ECC_PUBKEY_SIZE)
return -EINVAL;
^ permalink raw reply related
* [PATCH v2 1/2] crypto: atmel-i2c - improve comment in atmel_i2c_init_ecdh_cmd
From: Thorsten Blum @ 2026-06-09 10:05 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Clarify that a P-256 public key is encoded as two 32-byte coordinates.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
No changes in patch 1/2.
---
drivers/crypto/atmel-i2c.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-i2c.c b/drivers/crypto/atmel-i2c.c
index ff19857894d0..24bded47a32b 100644
--- a/drivers/crypto/atmel-i2c.c
+++ b/drivers/crypto/atmel-i2c.c
@@ -138,9 +138,8 @@ int atmel_i2c_init_ecdh_cmd(struct atmel_i2c_cmd *cmd,
cmd->param2 = cpu_to_le16(DATA_SLOT_2);
/*
- * The device only supports NIST P256 ECC keys. The public key size will
- * always be the same. Use a macro for the key size to avoid unnecessary
- * computations.
+ * The device only supports P-256. Its public key is encoded as
+ * two 32-byte coordinates.
*/
copied = sg_copy_to_buffer(pubkey,
sg_nents_for_len(pubkey,
base-commit: 79bbe453e5bfa6e1c6aa2e8329bfc8f152b81c9b
^ 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