* [PATCH 2/5] iommu/arm-smmu-v3: Add register display to debugfs
From: Qinxin Xia @ 2026-05-20 6:37 UTC (permalink / raw)
To: robin.murphy, nicolinc, will, jpb
Cc: linux-arm-kernel, iommu, xiaqinxin, wangzhou1, prime.zeng,
fanghao11, jonathan.cameron, wuyifan50, linuxarm, linux-kernel
In-Reply-To: <20260328101706.3448655-1-xiaqinxin@huawei.com>
Add register display functionality to debugfs.This allows reading
and displaying key SMMU register values including control registers
and queue pointers.
The registers file shows:
- CR0, CR1, CR2 control registers
- Command and Event queue pointers
Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
---
.../arm/arm-smmu-v3/arm-smmu-v3-debugfs.c | 82 +++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
index 1fc2cd1651b4..a541476b7427 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
@@ -6,12 +6,17 @@
* /sys/kernel/debug/iommu/arm_smmu_v3/
* └── smmu<ioaddr>/
* ├── capabilities # SMMU feature capabilities and configuration
+ * ├── registers # SMMU Key registers
*
* The capabilities file provides detailed information about:
* - translation stage support (Stage1/Stage2)
* - System coherency, ATS, and PRI feature availability
* - Stream table size and command/event queue depths
*
+ * The registers display provides crucial visibility into:
+ * - CR0, CR1, CR2 control registers
+ * - Command and Event queue pointers
+ *
* Copyright (C) 2026 HiSilicon Limited.
* Author: Qinxin Xia <xiaqinxin@huawei.com>
*/
@@ -95,6 +100,80 @@ static const struct file_operations smmu_debugfs_capabilities_fops = {
.release = smmu_debugfs_capabilities_release,
};
+/**
+ * smmu_debugfs_registers_show() - Display SMMU register values
+ * @seq: seq_file to write to
+ * @unused: unused parameter
+ *
+ * Errors are reported via seq_puts, the function always returns 0
+ */
+static int smmu_debugfs_registers_show(struct seq_file *seq, void *unused)
+{
+ struct arm_smmu_device *smmu = seq->private;
+ void __iomem *base;
+
+ if (!smmu || !smmu->base) {
+ seq_puts(seq, "SMMU not available\n");
+ return 0;
+ }
+
+ base = smmu->base;
+
+ seq_puts(seq, "SMMUv3 Key Registers:\n");
+
+ /* 32-bit control registers */
+ seq_printf(seq, "CR0: 0x%08x\n", readl_relaxed(base + ARM_SMMU_CR0));
+ seq_printf(seq, "CR1: 0x%08x\n", readl_relaxed(base + ARM_SMMU_CR1));
+ seq_printf(seq, "CR2: 0x%08x\n", readl_relaxed(base + ARM_SMMU_CR2));
+
+ /* 32-bit queue pointer registers */
+ seq_printf(seq, "CMDQ_PROD: 0x%08x\n",
+ readl_relaxed(base + ARM_SMMU_CMDQ_PROD));
+ seq_printf(seq, "CMDQ_CONS: 0x%08x\n",
+ readl_relaxed(base + ARM_SMMU_CMDQ_CONS));
+ seq_printf(seq, "EVTQ_PROD: 0x%08x\n",
+ smmu->page1 ? readl_relaxed(smmu->page1 + ARM_SMMU_EVTQ_PROD) : 0);
+ seq_printf(seq, "EVTQ_CONS: 0x%08x\n",
+ smmu->page1 ? readl_relaxed(smmu->page1 + ARM_SMMU_EVTQ_CONS) : 0);
+
+ return 0;
+}
+
+static int smmu_debugfs_registers_open(struct inode *inode, struct file *file)
+{
+ struct arm_smmu_device *smmu = inode->i_private;
+ int ret;
+
+ if (!smmu || !get_device(smmu->dev))
+ return -ENODEV;
+
+ ret = single_open(file, smmu_debugfs_registers_show, smmu);
+ if (ret)
+ put_device(smmu->dev);
+
+ return ret;
+}
+
+static int smmu_debugfs_registers_release(struct inode *inode, struct file *file)
+{
+ struct seq_file *seq = file->private_data;
+ struct arm_smmu_device *smmu = seq->private;
+
+ single_release(inode, file);
+ if (smmu)
+ put_device(smmu->dev);
+
+ return 0;
+}
+
+static const struct file_operations smmu_debugfs_registers_fops = {
+ .owner = THIS_MODULE,
+ .open = smmu_debugfs_registers_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = smmu_debugfs_registers_release,
+};
+
/**
* arm_smmu_debugfs_setup() - Initialize debugfs for SMMU device
* @smmu: SMMU device to setup debugfs for
@@ -142,6 +221,9 @@ int arm_smmu_debugfs_setup(struct arm_smmu_device *smmu, const char *name)
debugfs_create_file("capabilities", 0444, smmu_dir, smmu,
&smmu_debugfs_capabilities_fops);
+ debugfs_create_file("registers", 0444, smmu_dir, smmu,
+ &smmu_debugfs_registers_fops);
+
dev_dbg(smmu->dev, "debugfs initialized for %s\n", name);
return 0;
}
--
2.33.0
^ permalink raw reply related
* [PATCH 5/5] iommu/arm-smmu-v3: Add Context Descriptor display to debugfs
From: Qinxin Xia @ 2026-05-20 6:37 UTC (permalink / raw)
To: robin.murphy, nicolinc, will, jpb
Cc: linux-arm-kernel, iommu, xiaqinxin, wangzhou1, prime.zeng,
fanghao11, jonathan.cameron, wuyifan50, linuxarm, linux-kernel
In-Reply-To: <20260328101706.3448655-1-xiaqinxin@huawei.com>
Add Context Descriptor (CD) display functionality to debugfs.
This allow inspecting CD contents for all Substream IDs including:
- CD validity and translation parameters
- TTBR0 and TCR configurations
- Raw CD data
/sys/kernel/debug/iommu/arm_smmu_v3/smmu0/stream_table/
└── <sid>/
├─── ste
├─── cd
└─── <dev_name>
Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
---
.../arm/arm-smmu-v3/arm-smmu-v3-debugfs.c | 101 ++++++++++++++++++
1 file changed, 101 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
index 9babc7d640fd..567749de5537 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
@@ -10,6 +10,7 @@
* ├── stream_table
* ├── <sid>/ # Stream ID
* ├── ste # Stream Table Entry
+ * ├── cd # Context Descriptor
* ├── <dev_name> # Symlink to device sysfs directory
*
* The capabilities file provides detailed information about:
@@ -26,6 +27,12 @@
* - Stage 1 and Stage 2 context pointers
* - Raw STE data
*
+ * CD Information Displayed:
+ * - T0SZ: Input address space size configuration
+ * - EPD0/EPD1: Stage 1 translation enable flags
+ * - TTBR0: Stage 1 translation table base address
+ * - Raw Data: Complete CD structure in hexadecimal format
+ *
* Copyright (C) 2026 HiSilicon Limited.
* Author: Qinxin Xia <xiaqinxin@huawei.com>
*/
@@ -303,6 +310,97 @@ static const struct file_operations smmu_debugfs_ste_fops = {
.release = smmu_debugfs_ste_release,
};
+/**
+ * smmu_debug_dump_cd() - Dump a single Context Descriptor
+ * @seq: seq_file to write to
+ * @cd: pointer to the Context Descriptor to dump
+ */
+static void smmu_debug_dump_cd(struct seq_file *seq, struct arm_smmu_cd *cd)
+{
+ u64 data;
+ int i;
+
+ /* CD 0 */
+ data = le64_to_cpu(cd->data[0]);
+ seq_printf(seq, " T0SZ: 0x%llx\n", data & CTXDESC_CD_0_TCR_T0SZ);
+ seq_printf(seq, " EPD0: %s\n", data & CTXDESC_CD_0_TCR_EPD0 ? "Yes" : "No");
+ seq_printf(seq, " EPD1: %s\n", data & CTXDESC_CD_0_TCR_EPD1 ? "Yes" : "No");
+
+ /* CD 1 */
+ data = le64_to_cpu(cd->data[1]);
+ seq_printf(seq, " TTBR0: 0x%016llx\n", data & CTXDESC_CD_1_TTB0_MASK);
+
+ /* Display raw CD data */
+ seq_puts(seq, " Raw Data:\n");
+ for (i = 0; i < CTXDESC_CD_DWORDS; i++)
+ seq_printf(seq, " CD[%d]: 0x%016llx\n", i,
+ le64_to_cpu(cd->data[i]));
+}
+
+static int smmu_debugfs_cd_show(struct seq_file *seq, void *unused)
+{
+ struct device *dev = seq->private;
+ struct arm_smmu_master *master;
+ u32 max_ssids, ssid;
+
+ guard(mutex)(&arm_smmu_asid_lock);
+
+ master = dev_iommu_priv_get(dev);
+ if (!master) {
+ seq_puts(seq, "No master data\n");
+ return 0;
+ }
+
+ max_ssids = 1 << master->ssid_bits;
+ seq_printf(seq, "Context Descriptors for device (max SSIDs: %u):\n",
+ max_ssids);
+
+ for (ssid = 0; ssid < max_ssids; ssid++) {
+ struct arm_smmu_cd *cd = arm_smmu_get_cd_ptr(master, ssid);
+
+ if (cd && (le64_to_cpu(cd->data[0]) & CTXDESC_CD_0_V)) {
+ seq_printf(seq, "\n--- SSID %u ---\n", ssid);
+ smmu_debug_dump_cd(seq, cd);
+ }
+ }
+
+ return 0;
+}
+
+static int smmu_debugfs_cd_open(struct inode *inode, struct file *file)
+{
+ struct device *dev = inode->i_private;
+ int ret;
+
+ if (!dev || !get_device(dev))
+ return -ENODEV;
+
+ ret = single_open(file, smmu_debugfs_cd_show, dev);
+ if (ret)
+ put_device(dev);
+
+ return ret;
+}
+
+static int smmu_debugfs_cd_release(struct inode *inode, struct file *file)
+{
+ struct seq_file *seq = file->private_data;
+ struct device *dev = seq->private;
+
+ single_release(inode, file);
+ if (dev)
+ put_device(dev);
+ return 0;
+}
+
+static const struct file_operations smmu_debugfs_cd_fops = {
+ .owner = THIS_MODULE,
+ .open = smmu_debugfs_cd_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = smmu_debugfs_cd_release,
+};
+
/**
* arm_smmu_debugfs_create_stream_table() - Create debugfs entries for stream table
* @smmu: SMMU device
@@ -373,6 +471,9 @@ int arm_smmu_debugfs_create_stream_table(struct arm_smmu_device *smmu,
kfree(full_path);
}
}
+
+ /* Create CD file to dump all valid Context Descriptors */
+ debugfs_create_file("cd", 0444, dev_dir, dev, &smmu_debugfs_cd_fops);
}
kfree(path);
--
2.33.0
^ permalink raw reply related
* Re: [PATCH v1] crypto: Use named initializers for struct i2c_device_id
From: Ard Biesheuvel @ 2026-05-20 6:43 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Thorsten Blum,
Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260519141033.1586036-2-u.kleine-koenig@baylibre.com>
On Tue, 19 May 2026, at 16:10, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> This patch doesn't modify the compiled arrays, only their representation
> in source form benefits. The former was confirmed with x86 and arm64
> builds.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> this patch is part of a bigger quest to use named initializers for
> mainly struct i2c_device_id::driver_data to be able to modify
> i2c_device_id. See e.g.
> https://lore.kernel.org/all/20260518111203.639603-2-u.kleine-koenig@baylibre.com/
> for the details.
>
> This patch here isn't critical for this quest, as no driver makes use of
> .driver_data, so apart from the better readability this is only about
> consistency with other subsystems.
>
> Best regards
> Uwe
>
> drivers/crypto/atmel-ecc.c | 2 +-
> drivers/crypto/atmel-sha204a.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
> diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
> index 9c380351d2f9..56350454ac29 100644
> --- a/drivers/crypto/atmel-ecc.c
> +++ b/drivers/crypto/atmel-ecc.c
> @@ -380,7 +380,7 @@ MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
> #endif
>
> static const struct i2c_device_id atmel_ecc_id[] = {
> - { "atecc508a" },
> + { .name = "atecc508a" },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
> diff --git a/drivers/crypto/atmel-sha204a.c
> b/drivers/crypto/atmel-sha204a.c
> index dbb39ed0cea1..0fcb4692494f 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -210,8 +210,8 @@ static const struct of_device_id
> atmel_sha204a_dt_ids[] __maybe_unused = {
> MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
>
> static const struct i2c_device_id atmel_sha204a_id[] = {
> - { "atsha204" },
> - { "atsha204a" },
> + { .name = "atsha204" },
> + { .name = "atsha204a" },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(i2c, atmel_sha204a_id);
>
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> --
> 2.47.3
^ permalink raw reply
* Re: [PATCH v7 04/23] drm: bridge: dw_hdmi: Hold bridge ref until connector cleanup
From: Luca Ceresoli @ 2026-05-20 6:45 UTC (permalink / raw)
To: Jonas Karlman
Cc: Luca Ceresoli, Andrzej Hajda, Neil Armstrong, Robert Foss,
Heiko Stuebner, Laurent Pinchart, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Cristian Ciocaltea, Louis Chauvet, Liu Ying,
Sandy Huang, Andy Yan, Chen-Yu Tsai, Christian Hewitt,
Diederik de Haas, Nicolas Frattaroli, Dmitry Baryshkov, dri-devel,
linux-arm-kernel, linux-rockchip, linux-amlogic, linux-sunxi, imx,
linux-kernel
In-Reply-To: <e90eddfc-2f57-418a-ae05-43a411d72b99@kwiboo.se>
Hello Jonas,
On 2026-05-19 17:18 +0200, Jonas Karlman wrote:
> Hello Luca,
>
> On 5/19/2026 2:06 PM, Luca Ceresoli wrote:
> > On Mon, 18 May 2026 18:01:40 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
> >
> > Hello Jonas,
> >
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> index b7bfc0e9a6b2..9d795c550f8a 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> @@ -2600,10 +2609,14 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
> >>
> >> drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
> >>
> >> - drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
> >> - &dw_hdmi_connector_funcs,
> >> - DRM_MODE_CONNECTOR_HDMIA,
> >> - hdmi->ddc);
> >> + ret = drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
> >> + &dw_hdmi_connector_funcs,
> >> + DRM_MODE_CONNECTOR_HDMIA,
> >> + hdmi->ddc);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + drm_bridge_get(&hdmi->bridge);
> >
> > I'm not fully following the code paths, but both the report and the fix
> > make sense to me. Only I'd move the drm_bridge_get() before
> > drm_connector_init_with_ddc(), to avoid a short window where no reference
> > is held and the bridge might be destroyed before drm_bridge_get() is
> > called. I'm not sure this can happen, but it's better to write the code in
> > a way that clearly makes it impossible.
>
> dw_hdmi_connector_create() is only called from dw_hdmi_bridge_attach()
> so the bridge should already have a ref for the lifetime of this call.
Ah, that's true. So the patch is correct.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
In case you send a new iteration, please add this extra explanation to the
commit message, similar to the above paragraph.
> I explicitly chose the placement after drm_connector_init_with_ddc()
> to ensure ref count is correctly balanced without having to add a
> drm_bridge_put() call in any error path. I.e. connector destroy() is
> only called when drm_connector_init_with_ddc() succeeds.
>
> This code/call is also planned to be removed in a future series,
In order to remove the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case? That would be
welcome!
Luca
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits
From: Marc Zyngier @ 2026-05-20 6:52 UTC (permalink / raw)
To: Yao Yuan
Cc: Michael Bommarito, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <4v4zv3y5yxwkfnouqcjxhrwxvnpd7c4oodevrcgivxu2aeaiyg@2b3arv4mmv7n>
On Wed, 20 May 2026 07:04:26 +0100,
Yao Yuan <yaoyuan@linux.alibaba.com> wrote:
>
> On Mon, May 18, 2026 at 09:23:08AM +0800, Marc Zyngier wrote:
> > On Mon, 18 May 2026 07:05:13 +0100,
> > Yao Yuan <yaoyuan@linux.alibaba.com> wrote:
> > >
> > > On Sun, May 17, 2026 at 01:49:55PM +0800, Michael Bommarito wrote:
> >
> > [...]
> >
> > > > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
> > > > index 2ea9f1c7ebcd0..a5dcf9a6a2854 100644
> > > > --- a/arch/arm64/kvm/vgic/vgic-its.c
> > > > +++ b/arch/arm64/kvm/vgic/vgic-its.c
> > > > @@ -2307,6 +2307,15 @@ static int vgic_its_restore_dte(struct vgic_its *its, u32 id,
> > > > /* dte entry is valid */
> > > > offset = (entry & KVM_ITS_DTE_NEXT_MASK) >> KVM_ITS_DTE_NEXT_SHIFT;
> > > >
> > > > + /*
> > > > + * The MAPD command rejects this case; mirror the cap here so a
> > > > + * restored DTE cannot install an out-of-range num_eventid_bits
> > > > + * that vgic_its_restore_itt() would then convert into a
> > > > + * sign-extended scan_its_table() length.
> > > > + */
> > > > + if (num_eventid_bits > VITS_TYPER_IDBITS)
> > > > + return -EINVAL;
> > >
> > > Hi,
> > >
> > > IIUC, the same issue is still there when VITS_TYPER_IDBITS
> > > change to >=28, I know it's limited to 16 in GITS_TYPER's
> > > definition. I mean the issue is still there w/o really be
> > > fixed.
> >
> > Change how? This is a hard-coded limit that reflect a practical use of
> > the ITS (and is already 32 times larger than what PCIe allows).
> >
> > Are you suggesting a possibility of making this userspace
> > configurable?
>
> So far No, may until one day it has more than 16 definition :-)
This is 16 *bits*. That 2^16 possible MSIs *per device*. Please show
me a device that exceeds this requirement.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Robby Cai @ 2026-05-20 6:54 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam,
sebastian.krzyszkowiak, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <agcnS4H_XJRL7duw@lizhi-Precision-Tower-5810>
On Fri, May 15, 2026 at 10:01:47AM -0400, Frank Li wrote:
> On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> > Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> > on the i.MX8MQ EVK, and add two OV5640 camera sensors.
> >
> > The sensors are connected via I2C1 and I2C2, each with proper
> > endpoint descriptions to form complete media pipelines.
> >
> > The resulting pipelines are:
> >
> > - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
> > - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
> >
> > Both pipelines have been validated on the i.MX8MQ EVK using the
> > upstream OV5640 driver.
> >
> > Both OV5640 sensors share a single reset GPIO on this board,
> > which prevents independent hardware reset when both cameras
> > are enabled. As a result, the reset line is kept deasserted
> > via a GPIO hog, and sensor reset is performed via software.
>
> Does reset_control_get_shared() resolve this problem?
>
No, reset_control_get_shared() does not really solve this issue.
The problem here is not about software coordination, but about the
hardware topology: both sensors are physically tied to the same reset
line. This means any reset operation will always affect both devices
simultaneously, regardless of how the reset framework is used.
While reset_control_get_shared() introduces reference counting to avoid
unintended assertions, it does not allow independent reset control.
In particular:
- A reset operation (assert) will still impact both sensors.
- It does not solve the requirement for per-device hardware reset.
Therefore, using a shared reset control does not provide true isolation
between the two OV5640 instances.
Keeping the reset line permanently deasserted (e.g. via GPIO hog) and
handling initialization through software/power sequencing is a valid
and practical solution for this hardware design.
This matches the intention of the upstream changes as well, where GPIO-
based resets are treated as simple control signals rather than fully
isolated reset domains.
In practice, using a shared reset here can even introduce subtle
interference between the two cameras during probe or power cycling,
so it is safer to avoid using reset for runtime control entirely.
Regards,
Robby
^ permalink raw reply
* Re: [PATCH v7 2/6] dt-bindings: clock: airoha: Add PHY binding for Serdes port
From: Krzysztof Kozlowski @ 2026-05-20 6:53 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Lorenzo Bianconi, Felix Fietkau, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260519220813.28468-3-ansuelsmth@gmail.com>
On Wed, May 20, 2026 at 12:08:07AM +0200, Christian Marangi wrote:
> Add PHY cell property for Serdes port selection. Currently supported only
> for Airoha AN7581 SoC, that support up to 4 Serdes port.
>
> The Serdes port can support both PCIe, USB3 or Ethernet mode.
>
> The available Serdes port can be selected following the dt-binding header
> in [2].
>
> [2] <include/dt-bindings/soc/airoha,scu-ssr.h>
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> .../devicetree/bindings/clock/airoha,en7523-scu.yaml | 9 +++++++++
The bindings header should be squashed here as I asked previously.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 5/6] gpio: remove machine hogs
From: Bartosz Golaszewski @ 2026-05-20 6:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Bartosz Golaszewski, Linus Walleij, Geert Uytterhoeven,
Frank Rowand, Mika Westerberg, Andy Shevchenko, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Jonathan Corbet,
Shuah Khan, linux-gpio, linux-kernel, linux-acpi,
linux-arm-kernel, linux-omap, linux-doc
In-Reply-To: <ag1GJygtLgngKQqj@google.com>
On Wed, May 20, 2026 at 7:27 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> >
> > If there is no replacement maybe we can resurrect this? Or shoudl we
> > have add swnode support for hogs?
>
> Hmm, I guess it is already there so I should simply switch. Sorry about
> the noise.
>
Earlier in this series you have examples of using software node based
hogging, I hope you can use it?
Bart
^ permalink raw reply
* [PATCH v2 1/3] crypto: atmel-sha204a - Drop of_device_id data
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-20 7:01 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: Ard Biesheuvel, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1779260113.git.u.kleine-koenig@baylibre.com>
The driver binds to i2c devices only and thus in the absence of an
assignment for .data in the of_device_id array i2c_get_match_data()
falls back to .driver_data from the i2c_device_id array. So only provide
&atsha204_quality once to reduce duplication.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/crypto/atmel-sha204a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 6e6ac4770416..f17e1f6af1a3 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -208,8 +208,8 @@ static void atmel_sha204a_remove(struct i2c_client *client)
}
static const struct of_device_id atmel_sha204a_dt_ids[] = {
- { .compatible = "atmel,atsha204", .data = &atsha204_quality },
- { .compatible = "atmel,atsha204a", },
+ { .compatible = "atmel,atsha204" },
+ { .compatible = "atmel,atsha204a" },
{ }
};
MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/3] crypto - Rework i2c_device_id initialisation
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-20 7:01 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: Ard Biesheuvel, linux-crypto, linux-arm-kernel, linux-kernel
Hello,
this is v2 of the patch available at
https://lore.kernel.org/linux-crypto/20260519141033.1586036-2-u.kleine-koenig@baylibre.com.
Changes since v1 are:
- Rebase to next-20260519 to account for changes since v7.1-rc1 (= the
previous base)
- Patch #1 is new
- The adaption to atmel-sha204a is a bit less trivial, so split into a
separate patch (#2)
Best regards
Uwe
Uwe Kleine-König (The Capable Hub) (3):
crypto: atmel-sha204a - Drop of_device_id data
crypto: atmel-sha204a - Use named initializers for struct
i2c_device_id
crypto: atmel-ecc - Use named initializers for struct i2c_device_id
drivers/crypto/atmel-ecc.c | 4 ++--
drivers/crypto/atmel-sha204a.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
base-commit: 6a50ba100ace43f43c87384367eb2d2605fcc16c
--
2.47.3
^ permalink raw reply
* [PATCH v2 2/3] crypto: atmel-sha204a - Use named initializers for struct i2c_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-20 7:01 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: Ard Biesheuvel, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1779260113.git.u.kleine-koenig@baylibre.com>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits. The former was confirmed with x86 and arm64
builds.
For consistency also assign .driver_data for the array item that the
driver relies on i2c_get_match_data() returning NULL for.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/crypto/atmel-sha204a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index f17e1f6af1a3..f3bbe836778d 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -215,8 +215,8 @@ static const struct of_device_id atmel_sha204a_dt_ids[] = {
MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
static const struct i2c_device_id atmel_sha204a_id[] = {
- { "atsha204", (kernel_ulong_t)&atsha204_quality },
- { "atsha204a" },
+ { .name = "atsha204", .driver_data = (kernel_ulong_t)&atsha204_quality },
+ { .name = "atsha204a", .driver_data = (kernel_ulong_t)NULL },
{ }
};
MODULE_DEVICE_TABLE(i2c, atmel_sha204a_id);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 3/3] crypto: atmel-ecc - Use named initializers for struct i2c_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-20 7:01 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: Ard Biesheuvel, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1779260113.git.u.kleine-koenig@baylibre.com>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/crypto/atmel-ecc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 9660f6426a84..0ca02995a1de 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -376,8 +376,8 @@ static const struct of_device_id atmel_ecc_dt_ids[] = {
MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
static const struct i2c_device_id atmel_ecc_id[] = {
- { "atecc508a" },
- { "atecc608b" },
+ { .name = "atecc508a" },
+ { .name = "atecc608b" },
{ }
};
MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v7 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-05-20 7:05 UTC (permalink / raw)
To: Kevin Hilman
Cc: Andreas Kemnade, Bartosz Golaszewski, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Janusz Krzysztofik,
Tony Lindgren, Russell King, Dmitry Torokhov, Arnd Bergmann,
driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Aaro Koskinen
In-Reply-To: <agYB3-T9yz9-hdr4@darkstar.musicnaut.iki.fi>
On Thu, May 14, 2026 at 7:10 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>
> Hi,
>
> On Wed, May 13, 2026 at 02:59:26PM +0200, Andreas Kemnade wrote:
> > On Mon, 11 May 2026 15:34:39 +0200
> > Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > > This converts Nokia 770 to using real firmware node lookup for GPIOs by
> > > > attaching the software nodes describing GPIO controllers to their target
> > > > devices.
> > > >
> > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > >
> > > Hi!
> > >
> > > Gentle ping, can this be queued now for v7.2?
> > >
> > So any objections from your side, Aaro?
>
> It's fine.
>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
>
> A.
Kevin,
I think you offered to queue these patches before, can you take them for v7.2?
Thanks,
Bartosz
^ permalink raw reply
* [PACTH v2] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-20 7:09 UTC (permalink / raw)
To: o.rempel, kernel, andi.shyti, Frank.Li, s.hauer, festevam,
carlos.song, haibo.chen
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
From: Carlos Song <carlos.song@nxp.com>
Mark the I2C adapter as suspended during system suspend to block further
transfers, and resume it on system resume. This prevents potential hangs
when the hardware is powered down but clients still attempt I2C transfers.
Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
Change for v2:
- Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
to prevent potential deadlock if a transfer is active during suspend.
- Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
fails.
---
drivers/i2c/busses/i2c-imx.c | 34 ++++++++++++++++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index a208fefd3c3b..cf6e1333b084 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1913,6 +1913,36 @@ static int i2c_imx_runtime_resume(struct device *dev)
return ret;
}
+static int __maybe_unused i2c_imx_suspend_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ i2c_mark_adapter_suspended(&i2c_imx->adapter);
+
+ ret = pm_runtime_force_suspend(dev);
+ if (ret) {
+ i2c_mark_adapter_resumed(&i2c_imx->adapter);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused i2c_imx_resume_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
+ i2c_mark_adapter_resumed(&i2c_imx->adapter);
+
+ return 0;
+}
+
static int i2c_imx_suspend(struct device *dev)
{
/*
@@ -1946,8 +1976,8 @@ static int i2c_imx_resume(struct device *dev)
}
static const struct dev_pm_ops i2c_imx_pm_ops = {
- NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+ NOIRQ_SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend_noirq,
+ i2c_imx_resume_noirq)
SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend, i2c_imx_resume)
RUNTIME_PM_OPS(i2c_imx_runtime_suspend, i2c_imx_runtime_resume, NULL)
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-20 7:08 UTC (permalink / raw)
To: Chancel Liu (OSS), Chancel Liu
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, festevam@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org
In-Reply-To: <AM9PR04MB8353B563519EBC1AD6C5BFE1E3012@AM9PR04MB8353.eurprd04.prod.outlook.com>
On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
>>>>>>> +description:
>>>>>>> + The NXP I/O connector represents a physically present I/O
>>>>>>> +connector on the
>>>>>>> + base board. It acts as a nexus that exposes a constrained set
>> of
>>>>>>> +I/O
>>>>>>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
>>>>>>> +fixed
>>>>>>> + electrical wiring. All actual hardware providers reside on the
>> base
>>>> board.
>>>>>>> + The connector node only defines index-based mappings to those
>>>>>> providers.
>>>>>>> +
>>>>>>> +properties:
>>>>>>> + compatible:
>>>>>>> + const: fsl,io-connector
>>>>>>
>>>>>> Everything is IO. Everything is connector, so your compatible does
>>>>>> not match requirements from writing bindings.
>>>>>>
>>>>>
>>>>> Yes, this compatible is too generic. I will rename the compatible to
>>>>> fsl,aud-io-connector.
>>>>
>>>> aud is not much better. Which boards have it? What's the pinout?
>> What's
>>>> standard? Is it described anywhere? If so, provide reference to
>> spec/docs.
>>>>
>>>
>>> This is not an industry standard electrical interface. This connector
>>
>> Then if you do not have standard, then you have board specific layouts
>> thus you need board-specific compatibles. You can use fallbacks. Generic
>> fallback could work, but both io-connector and aud-io-connector are just
>> too generic. Every connector is "connector" and "io", thus absolutely
>> anything can be "io-connector". "aud" improves it only a bit, thus
>> honestly I would go with board specific fallback as well.
>>
>
> How about board specific + common fallback compatible like this:
> compatible:
> items:
> - enum:
> - fsl,imx95-19x19-evk-aud-io-connector
> - fsl,imx952-evk-aud-io-connector
> - const: fsl,imx-aud-io-connector
> Since the daughter board is named “IMX-AUD-IO” in publicly available
I don't think it is named like that.
git grep -i imx-aud-io
> documentation, common compatible clearly indicates that this connector
> is intended for that.
>
> Also, I want to talk about the topic of generic connector. It's a common
> design that daughter board is connected to base board through a
> connector. This connector more often acts as a nexus that exposes a
> constrained subset of GPIO, clock, PWM and interrupt resources to the
> daughter board. Can we document this kind of connector as a generic
> binding?
So this binding is the connector between carrier and some addon? Then
you don't get a compatible for that at all, because it is not necessary,
not useful and NEVER used. Do you see socket LGA "connector" bindings? No.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits
From: Marc Zyngier @ 2026-05-20 7:17 UTC (permalink / raw)
To: Oliver Upton, Michael Bommarito
Cc: Yao Yuan, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260519132519.2142458-1-michael.bommarito@gmail.com>
On Tue, 19 May 2026 09:25:19 -0400, Michael Bommarito wrote:
> Userspace can restore an ITS Device Table Entry whose Size field encodes
> more EventID bits than the virtual ITS supports. The live MAPD path
> rejects that state, but vgic_its_restore_dte() accepts it and stores the
> out-of-range value in dev->num_eventid_bits.
>
> Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before
> allocating the device. This mirrors the MAPD check and prevents the
> restored state from reaching vgic_its_restore_itt(), where the unchecked
> value can be converted into an oversized scan_its_table() range.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits
commit: 9ce754ed8e7ab4e3999767ce1505f85c449ccb07
Cheers,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: vgic: free private_irqs when init fails after allocation
From: Marc Zyngier @ 2026-05-20 7:17 UTC (permalink / raw)
To: Oliver Upton, Michael Bommarito
Cc: Yao Yuan, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260519135042.2219239-1-michael.bommarito@gmail.com>
On Tue, 19 May 2026 09:50:42 -0400, Michael Bommarito wrote:
> Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on
> failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy()
> call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The
> kvm_vgic_vcpu_init() failure path immediately above it has the same
> shape and still needs the same cleanup.
>
> Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private
> IRQs allocated before a redistributor iodev registration failure are
> released before the failed vCPU is freed.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: vgic: free private_irqs when init fails after allocation
commit: f19c354dbd457759dfcf1195ab4bdba2bb568323
Cheers,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
From: Marc Zyngier @ 2026-05-20 7:17 UTC (permalink / raw)
To: joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will,
Oliver Upton, Vincent Donnefort
Cc: linux-arm-kernel, kvmarm, kernel-team
In-Reply-To: <20260514162624.3477857-1-vdonnefort@google.com>
On Thu, 14 May 2026 17:26:24 +0100, Vincent Donnefort wrote:
> pKVM must validate the host-provided tracing buffer descriptor.
> However, if an error is found, the hypervisor would just return 0 to the
> host. Fix the return value on validation failure.
>
> While at it, rename the function to hyp_trace_desc_is_valid() and skip
> validation for the nVHE mode as we trust host-provided data in that
> case.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
commit: 1702da76e017ae0fbe1a92b07bc332972c293e89
Cheers,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2 0/7] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Uladzislau Rezki @ 2026-05-20 7:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
urezki, baohua, Xueyuan.chen21, dev.jain, rppt, david,
ryan.roberts, anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260519131738.11a78ba88e1be28ba5cb26eb@linux-foundation.org>
On Tue, May 19, 2026 at 01:17:38PM -0700, Andrew Morton wrote:
> On Thu, 14 May 2026 17:41:01 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous.
> >
> > ...
> >
> > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > the performance CPUfreq policy enabled, benchmark results:
> >
> > * ioremap(1 MB): 1.35× faster (3407 ns -> 2526 ns)
> > * vmalloc(1 MB) mapping time (excluding allocation) with
> > VM_ALLOW_HUGE_VMAP: 1.42× faster (5.00 us -> 3.53us)
> > * vmap(100MB) with order-8 pages: 8.3× faster (1235 us -> 149 us)
>
> Nice.
>
> AI review found a bunch of things to ask about:
> https://sashiko.dev/#/patchset/20260514094108.2016201-1-jiangwen6@xiaomi.com
>
> It doesn't appear that you'll be getting any more review on this
> series, so please check the above questions and resend?
>
Actually i keep an eye on it and i have done some stability testing.
So, just need some time. Fixing AI sounds good.
--
Uladzislau Rezki
^ permalink raw reply
* [PATCH v8] arm64: dts: imx95: Correct PCIe outbound address space configuration
From: Richard Zhu @ 2026-05-20 7:22 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
Fix the PCIe outbound memory ranges for both pcie0 and pcie1
controllers on i.MX95.
The memory window size was incorrectly set to 256MB during initial
bring-up, but the hardware supports up to 4GB of outbound address space
per controller.
Additionally, the ECAM region cannot be mapped as I/O space. Use a
memory-mapped region for I/O space instead, and relocate the 1MB I/O
region to immediately follow the memory region at offset 0xf0000000
within each window.
Update the outbound address space layout per controller as follows:
- 3.5GB 64-bit prefetchable memory
- 256MB 32-bit non-prefetchable memory
- 1MB I/O
Fixes: 3b1d5deb29ff ("arm64: dts: imx95: add pcie[0,1] and pcie-ep[0,1] support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
---
Changes in v8:
- Keep low address free, set the 32-bit non-prefetchable memory regioin
starting at 0xe0000000. Since PCI address 0x0 might break inbound DMA.
Changes in v7:
- Map the large outbound window into 64-bit PCI address, to eliminates both
the inbound DMA routing conflict and the IOVA exhaustion problem.
Changes in v6:
- Set the PCI I/O bus address starting at 0x0000_0000, while keeping the
CPU-side mapping at 0x9_f000_0000.
Changes in v5:
- Expand the outbound address space from 256MB to 3840MB, starting at the
base of each controller's assigned CPU address range.
- Use a memory region to map the I/O space.
Changes in v4:
Update the flag from 0x82000000 to 0x83000000 to declare a 64-bit PCI space.
Changes in v3:
Update the commit message, and set the region size to the max
hardware-supported memory space 4G.
Changes in v2:
Add the Fixes tag, and rebase to latest imx/dt64 branch.
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index adcc0e1d3696..60bf0932c6f7 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1939,8 +1939,9 @@ pcie0: pcie@4c300000 {
<0 0x4c360000 0 0x10000>,
<0 0x4c340000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
- <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
+ ranges = <0x43000000 0x9 0x00000000 0x9 0x00000000 0x0 0xe0000000>,
+ <0x82000000 0x0 0xe0000000 0x9 0xe0000000 0x0 0x10000000>,
+ <0x81000000 0x0 0x00000000 0x9 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -2014,8 +2015,9 @@ pcie1: pcie@4c380000 {
<0 0x4c3e0000 0 0x10000>,
<0 0x4c3c0000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0 0x00000000 0x8 0x8ff00000 0 0x00100000>,
- <0x82000000 0 0x10000000 0xa 0x10000000 0 0x10000000>;
+ ranges = <0x43000000 0xa 0x00000000 0xa 0x00000000 0x0 0xe0000000>,
+ <0x82000000 0x0 0xe0000000 0xa 0xe0000000 0x0 0x10000000>,
+ <0x81000000 0x0 0x00000000 0xa 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.37.1
^ permalink raw reply related
* Re: [PATCH v4 11/24] iommu: Add iommu_report_device_broken() to quarantine a broken device
From: Nicolin Chen @ 2026-05-20 7:20 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <20260520003023.GR3602937@nvidia.com>
On Tue, May 19, 2026 at 09:30:23PM -0300, Jason Gunthorpe wrote:
> On Tue, May 19, 2026 at 05:21:36PM -0700, Nicolin Chen wrote:
> > On Tue, May 19, 2026 at 08:02:04PM -0300, Jason Gunthorpe wrote:
> > > > OK. So you are suggesting a quarantine at the driver-level only:
> > > >
> > > > 1. Driver detects ATC_INV timeout during an invalidation.
> > > > 2. Driver retries the commands to identify the master.
> > >
> > > I might argue to push even this out to a followup series given it is
> > > complex and I suspect it becomes much simpler after the batch
> > > removal...
> >
> > I see you suggest to treat the entire batch as ATS-broken. Just to
> > confirm: without per-SID retry, that might falsely block a healthy
> > device in the ATC batch, right? The driver now batches all ATC_INV
> > commands via arm_smmu_invs_end_batch().
>
> Yes, it is not good, but a giant complex series is not reviewable. So
> I'd start with trashing all the devices, then come with a narrowing.
I can take that path for now and leave a FIXME.
Another option is to not batch multiple devices, until we support
retry (which shouldn't be hard to add since we've already done the
coding)?
> > > > 5. Driver sets master->ats_broken to fence concurrent attach:
> > > > arm_smmu_write_ste() and arm_smmu_ats_supported().
> > >
> > > Not sure this is needed, if we race some attach then the attach will
> > > re-set EATS, get another timeout and clear EATS. Doesn't seem worth
> > > trying to optimize for.
> >
> > I didn't see that coming. master->ats_enabled && state->ats_enabled
> > in the commit() for a concurrent attachment would issue an ATC that
> > may timeout again to re-start the step 1.
> >
> > And since arm_smmu_atc_inv_master() doesn't use domain->invs, it is
> > not affected by INV_TYPE_ATS_BROKEN. So, ATC_INV can continue to be
> > issued in this case.
> >
> > Ah, I feel that we are walking in the mine field where every single
> > step could be a kaboom. But your insight is clearly a safe pathway.
>
> We cannot eliminate parallel ATS invalidation. Two threads could be
> concurrently processing the invs list. So it has handle it, the driver
> is going to have to tolerate a number of redundant error events.
OK. That sounds like we still need a flag or locking so that at
least pci_disable_ats() would not be called again. I will see
what I can do.
> > > We do need to push a pci error event (didn't see that in this series)
> > > so the driver can catch it and start the FLR process. I suppose that
> > > will still need to bounce through a workqueue, and once you have that
> > > it can also set the blocked domain prior to calling out to the driver.
> >
> > In the specific case that I am trying to tackle with this series, I
> > do see AER error prints from the device already but there is no FLR
> > process.
>
> It depends on the driver, mlx5 has a FLR RAS flow for instance.
I assume a driver like that would trigger FLR flow on its own?
> A driver with a device that can blow up ATS should implement the FLR
> flow if it wants automatic RAS. It requires driver co-ordination.
Or FLR via sysfs, which I have been doing...
> But I wasn't thinking we can rely on existing AER events here, yes
> probably there will be AERs associated with the device exploding so
> badly it cannot do ATS, but also maybe not..
So, should I put the AER injection on hold for a future work? To
be honest, I am still not very clear how AER injection could help
here; or is it for a case where ATC times out while device isn't
aware of any AER fault?
> This is also a problem if we shoot healthy devices as the first stage,
> there will not be an AER from heathly..
>
> So I guess we need to decide which is better to tackle, the dedicated
> event or the single invalidation sequence..
I feel it safer to not break healthy devices. Otherwise, would a
nesting parent invalidation falsely block all devices, if one of
them times out?
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH 05/10] clk: amlogic: PLL l_detect signal supports active-high configuration
From: Jerome Brunet @ 2026-05-20 7:24 UTC (permalink / raw)
To: Jian Hu
Cc: Jian Hu via B4 Relay, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Xianwei Zhao, Kevin Hilman, Martin Blumenstingl, linux-kernel,
linux-clk, devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <d023303e-e785-4b60-85cd-c83cc3f890e4@amlogic.com>
On mer. 20 mai 2026 at 11:25, Jian Hu <jian.hu@amlogic.com> wrote:
> On 5/14/2026 11:13 PM, Jerome Brunet wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>>
>>> From: Jian Hu <jian.hu@amlogic.com>
>>>
>>> l_detect controls the enable/disable of the PLL lock-detect module.
>>>
>>> For A9, the l_detect signal is active-high:
>>> 0 -> Disable lock-detect module;
>>> 1 -> Enable lock-detect module.
>>>
>>> Here, a flag CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH is added to handle cases
>>> like A9, where the signal is active-high.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> drivers/clk/meson/clk-pll.c | 9 +++++++--
>>> drivers/clk/meson/clk-pll.h | 2 ++
>>> 2 files changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
>>> index 1ea6579a760f..5a0bd75f85a9 100644
>>> --- a/drivers/clk/meson/clk-pll.c
>>> +++ b/drivers/clk/meson/clk-pll.c
>>> @@ -388,8 +388,13 @@ static int meson_clk_pll_enable(struct clk_hw *hw)
>>> }
>>>
>>> if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
>>> - meson_parm_write(clk->map, &pll->l_detect, 1);
>>> - meson_parm_write(clk->map, &pll->l_detect, 0);
>>> + if (pll->flags & CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH) {
>>> + meson_parm_write(clk->map, &pll->l_detect, 0);
>>> + meson_parm_write(clk->map, &pll->l_detect, 1);
>>> + } else {
>>> + meson_parm_write(clk->map, &pll->l_detect, 1);
>>> + meson_parm_write(clk->map, &pll->l_detect, 0);
>>> + }
>> I'm not a fan of this code duplication.
>> Use the introduced CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH to compute the
>> first value, then flip the bit.
>
>
> Ok, I will update this in the next version.
>
> Here is the updated code:
>
> if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
> meson_parm_write(clk->map, &pll->l_detect,
> !(pll->flags &
> CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH));
> meson_parm_write(clk->map, &pll->l_detect,
> !!(pll->flags &
> CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH));
Please use a variable. Make it clean
> }
>
>>> }
>>>
>>> if (meson_clk_pll_wait_lock(hw))
>>> diff --git a/drivers/clk/meson/clk-pll.h b/drivers/clk/meson/clk-pll.h
>>> index 949157fb7bf5..97b7c70376a3 100644
>>> --- a/drivers/clk/meson/clk-pll.h
>>> +++ b/drivers/clk/meson/clk-pll.h
>>> @@ -29,6 +29,8 @@ struct pll_mult_range {
>>>
>>> #define CLK_MESON_PLL_ROUND_CLOSEST BIT(0)
>>> #define CLK_MESON_PLL_NOINIT_ENABLED BIT(1)
>>> +/* l_detect signal is active-high */
>>> +#define CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH BIT(2)
>>>
>>> struct meson_clk_pll_data {
>>> struct parm en;
>> --
>> Jerome
>
> Best regards,
>
> Jian
--
Jerome
^ permalink raw reply
* [GIT PULL] KVM/arm64 fixes for 7.1, take #3
From: Marc Zyngier @ 2026-05-20 7:25 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Michael Bommarito, Vincent Donnefort, Will Deacon, Yuan Yao,
Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, kvmarm, linux-arm-kernel, kvm
Paolo,
Here's the next set of KVM/arm64 fixes for 7.1. Continuing the trend,
we have two AI-fuelled fixes, both of which are stable candidates.
Additionally, a minor tidying-up of the hypervisor tracing descriptor
validation.
Please pull,
M.
The following changes since commit effc0a39b8e0f30670fe24f51e44329d4324e566:
KVM: arm64: Pre-check vcpu memcache for host->guest donate (2026-05-07 14:12:42 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-3
for you to fetch changes up to 1702da76e017ae0fbe1a92b07bc332972c293e89:
KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc (2026-05-20 08:08:37 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for 7.1, take #3
- Fix ITS EventID sanitisation when restoring an interrupt translation
table.
- Fix PPI memory leak when failing to initialise a vcpu.
- Correctly return an error when the validation of a hypervisor trace
descriptor fails, and limit this validation to protected mode only.
----------------------------------------------------------------
Michael Bommarito (2):
KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
KVM: arm64: vgic: Free private_irqs when init fails after allocation
Vincent Donnefort (1):
KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
arch/arm64/kvm/arm.c | 4 +++-
arch/arm64/kvm/hyp/nvhe/trace.c | 9 +++++++--
arch/arm64/kvm/vgic/vgic-its.c | 4 ++++
3 files changed, 14 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 0/5] KVM: arm64: nv: Implement nested stage-2 reverse map
From: Itaru Kitayama @ 2026-05-20 7:31 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon
In-Reply-To: <20260510145338.322962-1-weilin.chang@arm.com>
Hi Wei Lin,
On Sun, May 10, 2026 at 03:53:33PM +0100, Wei-Lin Chang wrote:
> Hi,
>
> This is v3 of optimizing the shadow s2 mmu unmapping during MMU
> notifiers.
>
> Two new preparatory patches are added, one reduces a hole in kvm_s2_mmu
> and another refactors the code a bit during s2 faults. Other changes are
> listed below.
>
> * Changes from v2 [1]:
>
> - Removed "polluted" teminology.
>
> - Use xa_{mk, to}_value() when storing and retriving values from maple
> trees.
>
> - Avoid using the 63rd bit in maple tree values so that xa_{mk, to}_value()
> does not lose us a bit.
>
> - Added reverse map removal during TLBI handling.
>
> - Other suggested refactorings.
>
> Thanks!
With this series applied on the recent kvmarm/fixes (minor local modification),
your v3 hello_nested runs fine on all three page granules; without this 16KB
kernel can't handle stage 2 unmapping paths. I tested using the latest QEMU only
so wonder how you're testing.
Thanks,
Itaru.
>
> [1]: https://lore.kernel.org/kvmarm/20260411125024.3735989-1-weilin.chang@arm.com/
>
> Wei-Lin Chang (5):
> KVM: arm64: Use a variable for the canonical GPA in kvm_s2_fault_map()
> KVM: arm64: Move shadow_pt_debugfs_dentry to reduce holes in
> kvm_s2_mmu
> KVM: arm64: nv: Avoid full shadow s2 unmap
> KVM: arm64: nv: Remove reverse map entries during TLBI handling
> KVM: arm64: nv: Create nested IPA direct map to speed up reverse map
> removal
>
> arch/arm64/include/asm/kvm_host.h | 17 +-
> arch/arm64/include/asm/kvm_nested.h | 6 +
> arch/arm64/kvm/mmu.c | 43 +++--
> arch/arm64/kvm/nested.c | 238 +++++++++++++++++++++++++++-
> arch/arm64/kvm/sys_regs.c | 3 +
> 5 files changed, 290 insertions(+), 17 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 6/7] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Uladzislau Rezki @ 2026-05-20 7:32 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260514094108.2016201-7-jiangwen6@xiaomi.com>
On Thu, May 14, 2026 at 05:41:07PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Try to align the vmap virtual address to PMD_SHIFT or a
> larger PTE mapping size hinted by the architecture, so
> contiguous pages can be batch-mapped when setting PMD or
> PTE entries.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index c30a7673e..b3389c8f1 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3591,6 +3591,35 @@ static int __vmap_huge(unsigned long addr, unsigned long end,
> return err;
> }
>
> +static struct vm_struct *get_aligned_vm_area(unsigned long size, unsigned long flags)
> +{
> + unsigned int shift = (size >= PMD_SIZE) ? PMD_SHIFT :
> + arch_vmap_pte_supported_shift(size);
> + struct vm_struct *vm_area = NULL;
> +
> + /*
> + * Try to allocate an aligned vm_area so contiguous pages can be
> + * mapped in batches.
> + */
> + while (1) {
> + unsigned long align = 1UL << shift;
> +
> + vm_area = __get_vm_area_node(size, align, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL,
> + __builtin_return_address(0));
> + if (vm_area || shift <= PAGE_SHIFT)
> + goto out;
> + if (shift == PMD_SHIFT)
> + shift = arch_vmap_pte_supported_shift(size);
> + else if (shift > PAGE_SHIFT)
> + shift = PAGE_SHIFT;
> + }
> +
> +out:
> + return vm_area;
> +}
> +
IMO, we should get rid of this while(1) loop. It looks like you need to
handle just few cases. 3?
shift min value is PAGE_SHIFT, could you please clarify when it can be less?
--
Uladzislau Rezki
^ 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