* Re: [PATCH] arm64: patching: replace min_t with min in __text_poke
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Catalin Marinas, Thorsten Blum
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel
In-Reply-To: <20260531220817.738904-2-thorsten.blum@linux.dev>
On Mon, 01 Jun 2026 00:08:16 +0200, Thorsten Blum wrote:
> Use the simpler min() macro since both values are unsigned and
> compatible.
>
>
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: patching: replace min_t with min in __text_poke
https://git.kernel.org/arm64/c/6c2ccb4979b2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 0/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: vladimir.murzin, xuwei5, broonie, ryan.roberts, corbet,
catalin.marinas, oupton, kevin.brodsky, maz, yeoreum.yun, skhan,
yangyicong, thuth, kuninori.morimoto.gx, lucaswei, lpieralisi,
miko.lenczewski, mark.rutland, james.clark, Zeng Heng
Cc: kernel-team, Will Deacon, wangkefeng.wang, linux-arm-kernel,
linux-kernel, linux-doc, zengheng4
In-Reply-To: <20260603062025.1504083-1-zengheng@huaweicloud.com>
On Wed, 03 Jun 2026 14:20:23 +0800, Zeng Heng wrote:
> v3: https://lore.kernel.org/all/20260601112000.1145391-1-zengheng@huaweicloud.com/
> v2: https://lore.kernel.org/all/20260529063132.766491-1-zengheng@huaweicloud.com/
> v1: https://lore.kernel.org/all/20260526015720.206854-1-zengheng@huaweicloud.com/
>
> Changes in v4:
> - Keep orthogonality for CONFIG_NVIDIA_CARMEL_CNP_ERRATUM and
> CONFIG_HISILICON_ERRATUM_162100125 within the cnp_erratum_cpus array.
>
> [...]
Applied to arm64 (for-next/errata), thanks!
[1/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
https://git.kernel.org/arm64/c/25996982ebcf
[2/2] arm64: kernel: Disable CNP on HiSilicon HIP09
https://git.kernel.org/arm64/c/f64328ecf4bf
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* [PATCH v1 0/4] iommufd: Cache invalidation hardening and SMMUv3 batching rework
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
Sashiko pointed out several issues in the iommufd invalidation path, which
also prompted a rework of the ARM SMMUv3 vIOMMU invalidation handler:
- entry_len is user-controlled and unbounded, so the trailing-zero check
for its forward-compat fields can scan gigabytes of user memory without
yielding, long enough to trip the soft-lockup watchdog.
- A large entry_num drives a backend's per-entry invalidation loop with no
reschedule, e.g. the VT-d nested path, pinning the CPU.
- The full-array copy helper copies the array twice on the equal-size fast
path: once in bulk, then again entry by entry.
- arm_vsmmu_cache_invalidate() reports converted-but-unsubmitted commands
as handled on its error paths.
- It sizes a single kernel allocation from the user-controlled entry_num.
- It rejects an empty-array data_type probe that the uAPI allows.
Fix them properly.
This is on Github:
https://github.com/nicolinc/iommufd/commits/smmuv3_fix_iommufd-v1
Nicolin Chen (4):
iommufd: Set upper bounds on cache invalidation entry_num and
entry_len
iommufd/selftest: Add invalidation entry_num and entry_len boundary
tests
iommu: Avoid copying the user array twice in the full-array copy
helper
iommu/arm-smmu-v3: Process vIOMMU invalidations in batches
include/linux/iommu.h | 1 +
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 91 +++++++++++--------
drivers/iommu/iommufd/hw_pagetable.c | 11 ++-
tools/testing/selftests/iommu/iommufd.c | 15 +++
4 files changed, 81 insertions(+), 37 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v1 2/4] iommufd/selftest: Add invalidation entry_num and entry_len boundary tests
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
Test that the cache invalidation ioctl rejects an oversized entry_len and
an oversized entry_num, covering the CPU soft-lockup paths the caps close.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
tools/testing/selftests/iommu/iommufd.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/tools/testing/selftests/iommu/iommufd.c b/tools/testing/selftests/iommu/iommufd.c
index d1fe5dbc2813e..653aa251f8122 100644
--- a/tools/testing/selftests/iommu/iommufd.c
+++ b/tools/testing/selftests/iommu/iommufd.c
@@ -556,6 +556,21 @@ TEST_F(iommufd_ioas, alloc_hwpt_nested)
1, &num_inv);
assert(!num_inv);
+ /* Negative test: entry_len is bounded by PAGE_SIZE */
+ num_inv = 1;
+ test_err_hwpt_invalidate(EINVAL, nested_hwpt_id[0], inv_reqs,
+ IOMMU_HWPT_INVALIDATE_DATA_SELFTEST,
+ PAGE_SIZE + 1, &num_inv);
+ assert(!num_inv);
+
+ /* Negative test: entry_num is bounded */
+#define IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX (1U << 19)
+ num_inv = IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX + 1;
+ test_err_hwpt_invalidate(EINVAL, nested_hwpt_id[0], inv_reqs,
+ IOMMU_HWPT_INVALIDATE_DATA_SELFTEST,
+ sizeof(*inv_reqs), &num_inv);
+ assert(!num_inv);
+
/* Negative test: invalid flag is passed */
num_inv = 1;
inv_reqs[0].flags = 0xffffffff;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/4] iommufd: Set upper bounds on cache invalidation entry_num and entry_len
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
iommufd_hwpt_invalidate() takes a user-controlled entry_num and entry_len,
each bounded only by U32_MAX. An entry_len beyond the kernel's struct size
makes the copy helper verify the extra bytes are zero, scanning that excess
in one uninterruptible pass; a multi-gigabyte value over zeroed user memory
trips the soft-lockup watchdog.
A large entry_num is the other half, driving the backend invalidation loop
with no reschedule. The VT-d nested handler, for one, copies each entry and
flushes caches per iteration, pinning the CPU on a non-preemptible kernel.
Cap both in the ioctl. entry_len is held under PAGE_SIZE, above any request
struct, and entry_num under 1 << 19, the order of a hardware invalidation
queue and well beyond any real batch, bounding the per-call loop length.
Fixes: 8c6eabae3807 ("iommufd: Add IOMMU_HWPT_INVALIDATE")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/iommufd/hw_pagetable.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommufd/hw_pagetable.c b/drivers/iommu/iommufd/hw_pagetable.c
index fe789c2dc0c97..623cc608ca0cd 100644
--- a/drivers/iommu/iommufd/hw_pagetable.c
+++ b/drivers/iommu/iommufd/hw_pagetable.c
@@ -489,6 +489,9 @@ int iommufd_hwpt_get_dirty_bitmap(struct iommufd_ucmd *ucmd)
return rc;
}
+/* An arbitrary entry_num cap, far above any realistic invalidation batch */
+#define IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX (1U << 19)
+
int iommufd_hwpt_invalidate(struct iommufd_ucmd *ucmd)
{
struct iommu_hwpt_invalidate *cmd = ucmd->cmd;
@@ -507,7 +510,13 @@ int iommufd_hwpt_invalidate(struct iommufd_ucmd *ucmd)
goto out;
}
- if (cmd->entry_num && (!cmd->data_uptr || !cmd->entry_len)) {
+ /*
+ * Bound entry_num and entry_len so a single call cannot pin the CPU;
+ * entry_len also caps the copy_struct_from_user() trailing-zero scan.
+ */
+ if (cmd->entry_num &&
+ (!cmd->data_uptr || !cmd->entry_len || cmd->entry_len > PAGE_SIZE ||
+ cmd->entry_num > IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX)) {
rc = -EINVAL;
goto out;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v1 4/4] iommu/arm-smmu-v3: Process vIOMMU invalidations in batches
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
arm_vsmmu_cache_invalidate() copies the entire user invalidation array into
one kernel allocation, then converts and submits those commands in batches
of CMDQ_BATCH_ENTRIES - 1. Sizing a single allocation from a user-supplied
count while tracking progress with a separate cursor is the root of several
independent problems:
- entry_num, the in/out count of successfully handled requests, is set to
"cur - cmds" on every error path. "cur" counts converted commands, not
submitted ones, so a conversion or submission failure reports the unsent
batch as handled, telling user space that invalidations which never made
it to the hardware have completed.
- The allocation is sized straight from the user's entry_num with no upper
bound and no __GFP_ACCOUNT, letting a large request drive an oversized,
unaccounted allocation and spam the page allocator.
- The -ENOMEM path returns without touching entry_num, once more reporting
the full input count as handled on a failure.
- A zero-length array, which the uAPI defines as a probe for a data_type
the kernel supports, reaches the full-array copy helper, which rejects
zero entries, so a supported type fails exactly like an unsupported one.
Rework the function to process the array one batch at a time, copying up to
CMDQ_BATCH_ENTRIES - 1 entries into a fixed-size stack buffer, converting
them in place, and issuing the batch, which removes the user-sized buffer.
A refactor is preferred over a series of smaller fixes because the problems
above are symptoms of one structure; changing the structure removes them as
a class rather than patching each in place:
- Dropping the allocation makes the size bound, the __GFP_ACCOUNT, and the
-ENOMEM accounting question moot, not three separate fixes.
- entry_num advances only as batches are issued, so the count it reports
tracks submitted commands and needs no correction on the error paths.
- The type is checked once up front, and an empty array then iterates zero
times, so the probe case falls out for free.
Each batch is still copied in one bulk transfer via the full-array helper,
iommu_copy_struct_from_full_user_array(); the whole-array copy becomes one
copy per batch that the preceding helper fix keeps to a single bulk copy.
If converting an entry fails, the already-converted prefix of the batch is
issued before the error is returned; if that issue fails, the batch is not
counted. So entry_num stays tied only to commands that actually reached the
hardware, without dropping the valid ones that preceded the failure.
Fixes: d68beb276ba2 ("iommu/arm-smmu-v3: Support IOMMU_HWPT_INVALIDATE using a VIOMMU object")
Assisted-by: Codex:GPT-5
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 91 +++++++++++--------
1 file changed, 55 insertions(+), 36 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
index ddae0b07c76b5..5574ccaecf381 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
@@ -350,53 +350,72 @@ static int arm_vsmmu_convert_user_cmd(struct arm_vsmmu *vsmmu,
return 0;
}
-int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
- struct iommu_user_data_array *array)
+static int arm_vsmmu_cache_invalidate_batch(struct arm_vsmmu *vsmmu,
+ struct iommu_user_data_array *array,
+ u32 *idx)
{
- struct arm_vsmmu *vsmmu = container_of(viommu, struct arm_vsmmu, core);
+ struct arm_vsmmu_invalidation_cmd cmds[CMDQ_BATCH_ENTRIES - 1];
struct arm_smmu_device *smmu = vsmmu->smmu;
- struct arm_vsmmu_invalidation_cmd *last;
- struct arm_vsmmu_invalidation_cmd *cmds;
- struct arm_vsmmu_invalidation_cmd *cur;
- struct arm_vsmmu_invalidation_cmd *end;
- int ret;
-
- cmds = kzalloc_objs(*cmds, array->entry_num);
- if (!cmds)
- return -ENOMEM;
- cur = cmds;
- end = cmds + array->entry_num;
+ struct iommu_user_data_array batch = {
+ .type = array->type,
+ .entry_len = array->entry_len,
+ };
+ unsigned int num, i;
+ int ret, issue_ret;
static_assert(sizeof(*cmds) == 2 * sizeof(u64));
+
+ /* Copy one batch of the user array in a single bulk copy */
+ num = min_t(u32, array->entry_num - *idx, ARRAY_SIZE(cmds));
+ batch.uptr = array->uptr + array->entry_len * *idx;
+ batch.entry_num = num;
ret = iommu_copy_struct_from_full_user_array(
- cmds, sizeof(*cmds), array,
+ cmds, sizeof(*cmds), &batch,
IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3);
if (ret)
- goto out;
-
- last = cmds;
- while (cur != end) {
- ret = arm_vsmmu_convert_user_cmd(vsmmu, cur);
- if (ret)
- goto out;
-
- /* FIXME work in blocks of CMDQ_BATCH_ENTRIES and copy each block? */
- cur++;
- if (cur != end && (cur - last) != CMDQ_BATCH_ENTRIES - 1)
- continue;
+ return ret;
- /* FIXME always uses the main cmdq rather than trying to group by type */
- ret = arm_smmu_cmdq_issue_cmdlist(smmu, &smmu->cmdq, last->cmd,
- cur - last, true);
+ /* Convert in place; only the converted prefix may be issued */
+ for (i = 0; i < num; i++) {
+ ret = arm_vsmmu_convert_user_cmd(vsmmu, &cmds[i]);
if (ret) {
- cur--;
- goto out;
+ num = i;
+ break;
}
- last = cur;
}
-out:
- array->entry_num = cur - cmds;
- kfree(cmds);
+ if (!num)
+ return ret;
+
+ /* FIXME always uses the main cmdq rather than trying to group by type */
+ issue_ret = arm_smmu_cmdq_issue_cmdlist(smmu, &smmu->cmdq, cmds->cmd,
+ num, true);
+ if (issue_ret)
+ return issue_ret;
+
+ *idx += num;
+ return ret;
+}
+
+int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
+ struct iommu_user_data_array *array)
+{
+ struct arm_vsmmu *vsmmu = container_of(viommu, struct arm_vsmmu, core);
+ u32 issued = 0;
+ int ret = 0;
+
+ if (array->type != IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3) {
+ array->entry_num = 0;
+ return -EINVAL;
+ }
+
+ while (issued != array->entry_num) {
+ /* Process and issue the command(s) in batch */
+ ret = arm_vsmmu_cache_invalidate_batch(vsmmu, array, &issued);
+ if (ret)
+ break;
+ }
+
+ array->entry_num = issued;
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v1 3/4] iommu: Avoid copying the user array twice in the full-array copy helper
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
iommu_copy_struct_from_full_user_array() copies a whole user array into a
kernel buffer. In the common case, where user entry_len equals destination
entry size, it takes a fast path and copies the whole array with a single
copy_from_user().
That fast path does not return, so it falls through into the item-by-item
copy_struct_from_user() loop and copies every entry a second time. For an
equal entry_len that loop is just a copy_from_user() of the same bytes, so
the whole array is copied twice for no benefit.
Return right after the bulk copy. The per-item loop then runs only on the
slow path, where entry_len differs and each entry needs size adaption.
Fixes: 4f2e59ccb698 ("iommu: Add iommu_copy_struct_from_full_user_array helper")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e587d4ac4d331..6957144263793 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -547,6 +547,7 @@ iommu_copy_struct_from_full_user_array(void *kdst, size_t kdst_entry_size,
user_array->entry_num *
user_array->entry_len))
return -EFAULT;
+ return 0;
}
/* Copy item by item */
--
2.43.0
^ permalink raw reply related
* [PATCH] clk: rockchip: don't COMPILE_TEST builds on M68K
From: Heiko Stuebner @ 2026-06-03 21:37 UTC (permalink / raw)
To: heiko
Cc: rosenp, linux-arm-kernel, linux-rockchip, linux-clk,
kernel test robot
Rockchip clock drivers use hash-tables with enums as inputs.
M68K does interesting things in its __hash_32() implementation, casting
that u32 input to an u16 and therefore triggering warnings like:
drivers/clk/rockchip/clk-rk3528.c: note: in included file (through include/linux/hash.h, include/linux/slab.h):
arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (1e8e8 becomes e8e8)
As M68K should never ever need Rockchip clock drivers, simply disable
compile-tests for M68K.
Fixes: 7edfb7fb58ee ("clk: rockchip: allow COMPILE_TEST builds")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605191434.PQkj2Rki-lkp@intel.com/
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/clk/rockchip/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/Kconfig b/drivers/clk/rockchip/Kconfig
index 85133498f013..8b49fe6f46fb 100644
--- a/drivers/clk/rockchip/Kconfig
+++ b/drivers/clk/rockchip/Kconfig
@@ -4,6 +4,7 @@
config COMMON_CLK_ROCKCHIP
bool "Rockchip clock controller common support"
depends on ARCH_ROCKCHIP || COMPILE_TEST
+ depends on !M68K
default ARCH_ROCKCHIP
help
Say y here to enable common clock controller for Rockchip platforms.
--
2.47.3
^ permalink raw reply related
* Re: [PATCH net next] net: axienet: Use dedicated ethtool_ops for the dmaengine path
From: Jacob Keller @ 2026-06-03 22:02 UTC (permalink / raw)
To: Suraj Gupta, andrew+netdev, davem, edumazet, kuba, pabeni,
michal.simek, sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
In-Reply-To: <20260601124454.3384601-1-suraj.gupta2@amd.com>
On 6/1/2026 5:44 AM, Suraj Gupta wrote:
> The dmaengine path shares ethtool_ops with the legacy AXI DMA path,
> including .get_coalesce/.set_coalesce that poke XAXIDMA_*_CR_OFFSET
> directly. In dmaengine mode lp->dma_regs is not mapped by axienet, so
> those ethtool calls touch unmapped/unrelated memory and report values
> unrelated to the channel actually in use.
>
> .get_ringparam/.set_ringparam only touch lp->rx_bd_num/lp->tx_bd_num,
> fields used only by the legacy path for BD ring sizing. In dmaengine
> mode the descriptor ring is owned by the dmaengine provider and these
> fields are not consulted, so reporting them is misleading.
>
> No dmaengine API exists today to query or program either coalescing
> or ring size on behalf of the client, so neither can be exposed
> meaningfully in dmaengine mode.
>
> Add axienet_ethtool_dmaengine_ops without the coalesce and ringparam
> hooks. Also move the ethtool_ops assignment from early probe into the
> if/else alongside netdev_ops, so the legacy and dmaengine paths pick
> their respective ops in one place. No functional change for the
> legacy DMA path.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 27 ++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 263c4b67fd5a..fcf517069d16 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -2536,6 +2536,25 @@ static const struct ethtool_ops axienet_ethtool_ops = {
> .get_rmon_stats = axienet_ethtool_get_rmon_stats,
> };
>
> +static const struct ethtool_ops axienet_ethtool_dmaengine_ops = {
> + .get_drvinfo = axienet_ethtools_get_drvinfo,
> + .get_regs_len = axienet_ethtools_get_regs_len,
> + .get_regs = axienet_ethtools_get_regs,
> + .get_link = ethtool_op_get_link,
> + .get_pauseparam = axienet_ethtools_get_pauseparam,
> + .set_pauseparam = axienet_ethtools_set_pauseparam,
> + .get_link_ksettings = axienet_ethtools_get_link_ksettings,
> + .set_link_ksettings = axienet_ethtools_set_link_ksettings,
> + .nway_reset = axienet_ethtools_nway_reset,
> + .get_ethtool_stats = axienet_ethtools_get_ethtool_stats,
> + .get_strings = axienet_ethtools_get_strings,
> + .get_sset_count = axienet_ethtools_get_sset_count,
> + .get_pause_stats = axienet_ethtools_get_pause_stats,
> + .get_eth_mac_stats = axienet_ethtool_get_eth_mac_stats,
> + .get_eth_ctrl_stats = axienet_ethtool_get_eth_ctrl_stats,
> + .get_rmon_stats = axienet_ethtool_get_rmon_stats,
> +};
> +
> static struct axienet_local *pcs_to_axienet_local(struct phylink_pcs *pcs)
> {
> return container_of(pcs, struct axienet_local, pcs);
> @@ -2792,7 +2811,6 @@ static int axienet_probe(struct platform_device *pdev)
>
> SET_NETDEV_DEV(ndev, &pdev->dev);
> ndev->features = NETIF_F_SG;
> - ndev->ethtool_ops = &axienet_ethtool_ops;
>
> /* MTU range: 64 - 9000 */
> ndev->min_mtu = 64;
> @@ -3021,10 +3039,13 @@ static int axienet_probe(struct platform_device *pdev)
> lp->use_dmaengine = 1;
> }
>
> - if (lp->use_dmaengine)
> + if (lp->use_dmaengine) {
> ndev->netdev_ops = &axienet_netdev_dmaengine_ops;
> - else
> + ndev->ethtool_ops = &axienet_ethtool_dmaengine_ops;
> + } else {
> ndev->netdev_ops = &axienet_netdev_ops;
> + ndev->ethtool_ops = &axienet_ethtool_ops;
> + }
> /* Check for Ethernet core IRQ (optional) */
> if (lp->eth_irq <= 0)
> dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
^ permalink raw reply
* Re: [PATCH v3 2/2] kconfig: Remove the architecture specific config for Propeller
From: Rong Xu @ 2026-06-03 22:15 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Will Deacon, Yabin Cui, Han Shen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kees Cook,
Nicolas Schier, Linus Walleij, Arnd Bergmann, Mathieu Desnoyers,
Miguel Ojeda, Peter Zijlstra, Jinjie Ruan, Lukas Bulwahn,
linux-kernel, Juergen Gross, Helge Deller, Ryan Roberts,
Marc Zyngier, Ard Biesheuvel, Vincent Donnefort, Alice Ryhl, x86,
linux-arm-kernel
In-Reply-To: <20260603015354.GD1940387@ax162>
On Tue, Jun 2, 2026 at 6:54 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Tue, Jun 02, 2026 at 10:52:48AM -0700, Rong Xu wrote:
> > On Tue, Jun 2, 2026 at 2:43 AM Will Deacon <will@kernel.org> wrote:
> > > I still don't think it has anything to do with the arch. If the compiler
> > > supports the option, then we can use it. The arch code in the kernel
> > > doesn't need to do anything, right? So can you just check if the
> > > compiler accepts the option using a 'depends on $(cc-option, ...)' line?
> >
> > Yes, arch code in the kernel does not need to do anything—it is just a marker.
> >
> > I understand your concern. I can use (cc-options,...) in PROPELLER_CLANG config.
> > But I will not use -fbasic-block-address-map for backward compatiliby reason.
> > I would use "-fbasic-block-sections=list=/dev/null".
> >
> > I'll send the updated patch shortly.
>
> Technically, an architecture needs to add the section generated by this
> compiler option to their linker script to avoid an orphan section
> warning (or error from CONFIG_WERROR) if enabled, as has been done in
> this series.
>
> I worry that moving to a dynamic check will cause build breakage if an
> LLVM target gains support for Propeller without having their kernel
> image linker script adjusted. Maybe that will not happen very often and
> even if it does, I do not mind taking on the maintenance burden of
> fixing it but there is a cost of moving to a dynamic check like this.
>
This is true.
That said, these orphan sections usually won't impact correctness. The
linker will group these together even withgout the link script change,
even though it generates a lot of warnings.
With moving to a dynamic check, correct usage of this feature remains
the user's responsibility -- I think this is Will's point from the
very beginning.
As noted in your previous response, the dynamic check is primarily
intended to prevent "allmodconfig" build failures.
I am comfortable with either the arch_kconfig or dynamic_check
approach. Once a preferred solution is decided, please let me know so
I can submit v4 for review.
Thanks,
-Rong
> --
> Cheers,
> Nathan
^ permalink raw reply
* Re: [PATCH v7 10/11] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Daniel Mentz @ 2026-06-03 22:18 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Nicolin Chen, iommu, Will Deacon, Joerg Roedel, Robin Murphy,
Jason Gunthorpe, Mostafa Saleh, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <ahi3uY9YZZtR1Lq5@google.com>
On Thu, May 28, 2026 at 2:46 PM Pranjal Shrivastava <praan@google.com> wrote:
>
> On Thu, May 28, 2026 at 01:28:15PM -0700, Nicolin Chen wrote:
> > On Wed, May 27, 2026 at 10:14:06PM +0000, Pranjal Shrivastava wrote:
> > > TLB and CFG invalidations are
> > > elided if the SMMU is suspended by observing the CMDQ_PROD_STOP_FLAG via
> > > the arm_smmu_can_elide() helper.
> >
> > All the arm_smmu_can_elide() call sites here would eventually elide
> > the commands in arm_smmu_cmdq_issue_cmdlist() that is already gated
> > by CMDQ_PROD_STOP_FLAG? It doesn't seem necessary to gate again?
>
> While issue_cmdlist() would eventually elide these commands, the
> can_elide() check is necessary to return early during suspension.
>
> This avoids unnecessary stack allocation, cmd building, and spinlock
> contention on the cmdq->lock for threads that are anyway about to be
> elided.
>
> By dropping these requests immediately, we significantly reduce cacheline
> bouncing and contention during unmap storms. Furthermore, the early check
> also allows us to specifically trigger the WARN_ON_ONCE() for broken
> devlinks.
Hi Pranjal,
Have you observed unmap storms in a real-world use case, or is this a
preemptive optimization? I would not expect a high rate of map/unmap
operations while the SMMU is suspended. If a client device calls
iommu_map/iommu_unmap (directly or indirectly), it suggests the client
device is RPM_ACTIVE, meaning the SMMU should be active as well.
I am in favor of removing arm_smmu_can_elide().
^ permalink raw reply
* [PATCH v1 0/2] arm64: dts: imx8mm-var-som-symphony: minor board updates
From: Stefano Radaelli @ 2026-06-03 22:53 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
This series contains minor updates for the Variscite Symphony carrier
board based on the current hardware configuration.
It updates the RGB_SEL handling and marks the relevant input devices as
wakeup sources.
Stefano Radaelli (2):
arm64: dts: imx8mm-var-som-symphony: add wakeup sources
arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
.../boot/dts/freescale/imx8mm-var-som-symphony.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
base-commit: be580423d3f84b84a2f549df91e66bc4f54eda02
--
2.47.3
^ permalink raw reply
* [PATCH v1 2/2] arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
From: Stefano Radaelli @ 2026-06-03 22:54 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780527068.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Keep the RGB_SEL line driven low on the Symphony carrier board.
This avoids leaving the line floating and ensures the board remains in
the expected display configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 090752014ee2..fd0a1862ce90 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -168,6 +168,14 @@ pca6408: gpio@21 {
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
+
+ /* RGB_SEL */
+ lvds-brg-enable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "rgb_sel";
+ };
};
st33ktpm2xi2c: tpm@2e {
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/2] arm64: dts: imx8mm-var-som-symphony: add wakeup sources
From: Stefano Radaelli @ 2026-06-03 22:53 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780527068.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Mark the Symphony carrier board GPIO keys and capacitive touchscreen as
wakeup sources.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 857325ef4461..090752014ee2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -55,18 +55,21 @@ key-back {
label = "Back";
gpios = <&pca9534 1 GPIO_ACTIVE_LOW>;
linux,code = <KEY_BACK>;
+ wakeup-source;
};
key-home {
label = "Home";
gpios = <&pca9534 2 GPIO_ACTIVE_LOW>;
linux,code = <KEY_HOME>;
+ wakeup-source;
};
key-menu {
label = "Menu";
gpios = <&pca9534 3 GPIO_ACTIVE_LOW>;
linux,code = <KEY_MENU>;
+ wakeup-source;
};
};
@@ -187,6 +190,7 @@ ft5x06_ts: touchscreen@38 {
touchscreen-size-y = <480>;
touchscreen-inverted-x;
touchscreen-inverted-y;
+ wakeup-source;
};
rtc@68 {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 7/7] arm64: dts: qcom: Add #{address,size}-cells to Chromium-based /firmware
From: Dmitry Baryshkov @ 2026-06-03 22:59 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Heiko Stuebner, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Konrad Dybcio,
devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, linux-rockchip, Julius Werner, Alim Akhtar,
cros-qcom-dts-watchers, linux-arm-msm, linux-tegra,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260428200712.2660635-8-briannorris@chromium.org>
On Tue, Apr 28, 2026 at 01:06:59PM -0700, Brian Norris wrote:
> Chromium/Depthcharge bootloaders may dynamically add a few device nodes
> to a system's DTB under a /firmware node. A typical DT looks something
> like the following:
>
> / {
> firmware {
> ranges;
>
> coreboot {
> compatible = "coreboot";
> reg = <...>;
> ...;
> };
> };
> };
>
> Notably, the /firmware node has an empty 'ranges', but does not have
> address/size-cells.
>
> Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating
> non-translatable addresses") started requiring #address-cells for a
> device's parent if we want to use the reg resource in a device node.
> This leads to errors like the following:
>
> [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> Add appropriate #{address,size}-cells to work around the problem.
>
> Note that Google has also patched the Depthcharge bootloader source to
> add {address,size}-cells [1], but bootloader updates are typically
> delivered only via Google OS updates. Not all users install Google
> software updates, and even if they do, Google may not produce updated
> binaries for all/older devices.
>
> [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/
> https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
> #size-cells for firmware node")
>
> Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
> Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
From: Oliver Upton @ 2026-06-03 23:07 UTC (permalink / raw)
To: Hyunwoo Kim
Cc: maz, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, stable
In-Reply-To: <aiAZfdeyanIvP8SD@v4bel>
On Wed, Jun 03, 2026 at 09:09:33PM +0900, Hyunwoo Kim wrote:
> walk_s1() and kvm_walk_nested_s2() expect to be called while holding
> kvm->srcu to guard against memslot changes. While this is generally
> the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the
> respective walkers without taking kvm->srcu.
>
> Fix by acquiring kvm->srcu prior to the table walk in both instances.
>
> Cc: stable@vger.kernel.org
> Fixes: 50f77dc87f13 ("KVM: arm64: Populate level on S1PTW SEA injection")
> Fixes: be04cebf3e78 ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}")
> Suggested-by: Oliver Upton <oupton@kernel.org>
> Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Reviewed-by: Oliver Upton <oupton@kernel.org>
--
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: Dmitry Baryshkov @ 2026-06-03 23:08 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-1-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:26PM +0530, Nabige Aala wrote:
> Shikra SoC uses the same MDSS/DPU/DSI hardware as QCM2290 (DPU 6.5),
> sharing the same register layout, DSI controller and 14nm DSI PHY.
> Add qcom,shikra-mdss to the qcm2290-mdss binding compatible enum
> rather than introducing a separate binding file.
Why are you introducing the sole compat string instead of using Agatti
one as a fallback?
>
> Register qcom,shikra-dsi-ctrl in dsi-controller-main.yaml alongside
> qcom,qcm2290-dsi-ctrl, and update the qcm2290-mdss patternProperties
> to accept both SoC-specific DPU and DSI controller compatibles.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> .../bindings/display/msm/dsi-controller-main.yaml | 1 +
> .../bindings/display/msm/qcom,qcm2290-dpu.yaml | 4 ++-
> .../bindings/display/msm/qcom,qcm2290-mdss.yaml | 34 +++++++++++++++++-----
> 3 files changed, 31 insertions(+), 8 deletions(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/5] drm/msm/mdss: Add Shikra support
From: Dmitry Baryshkov @ 2026-06-03 23:09 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-2-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:27PM +0530, Nabige Aala wrote:
> Add Mobile Display Subsystem (MDSS) support for the Shikra platform.
> Shikra uses the same MDSS and DPU 6.5 hardware as QCM2290, so it
> reuses the same AHB clock rate configuration (data_76k8) and DPU
> catalog. Register qcom,shikra-dpu in the DPU KMS match table pointing
> to dpu_qcm2290_cfg.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> drivers/gpu/drm/msm/msm_mdss.c | 1 +
> 2 files changed, 2 insertions(+)
>
This points out that the previous comment was correct. Drop this patch
and use compat strings.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/5] arm64: defconfig: Enable ILI7807S DSI panel driver
From: Dmitry Baryshkov @ 2026-06-03 23:09 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-3-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:28PM +0530, Nabige Aala wrote:
> Enable the ILI7807S 1080x1920 video-mode DSI panel driver as a module,
> used on the Shikra CQM EVK board.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 5/5] iommu/arm-smmu: Add qcom,shikra-mdss to Qualcomm SMMU client tables
From: Dmitry Baryshkov @ 2026-06-03 23:11 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-5-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:30PM +0530, Nabige Aala wrote:
> Register the Shikra MDSS display subsystem in both the SMMU ACTLR
> client table (for TLB prefetch tuning) and the SMMU client match table.
>
> Shikra MDSS uses qcom,shikra-mdss as its sole compatible string, so
> explicit entries are required — there is no fallback to qcom,qcm2290-mdss
> to fall back on. The prefetch settings mirror qcm2290-mdss
> (PREFETCH_SHALLOW | CPRE | CMTLB) as Shikra shares the same display
> hardware block.
>
> No entry is needed in qcom_smmu_impl_of_match: Shikra's apps_smmu
> carries qcom,smmu-500 as a fallback and is covered by the catch-all
> entry there.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 +++
> 1 file changed, 3 insertions(+)
>
NAK, use qcm2290 as a fallback. You won't need this patch.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 4/5] soc: qcom: ubwc: Add Shikra UBWC config
From: Dmitry Baryshkov @ 2026-06-03 23:12 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-4-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:29PM +0530, Nabige Aala wrote:
> Add UBWC configuration for the Shikra platform. Shikra has no UBWC
> support and no highest_bank_bit setting, so use no_ubwc_data.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ubwc_config.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/qcom/ubwc_config.c b/drivers/soc/qcom/ubwc_config.c
> index 3fe47d8f0f63..01dca97e2671 100644
> --- a/drivers/soc/qcom/ubwc_config.c
> +++ b/drivers/soc/qcom/ubwc_config.c
> @@ -278,6 +278,7 @@ static const struct of_device_id qcom_ubwc_configs[] __maybe_unused = {
> { .compatible = "qcom,sdm660", .data = &msm8937_data },
> { .compatible = "qcom,sdm670", .data = &sdm670_data, },
> { .compatible = "qcom,sdm845", .data = &sdm845_data, },
> + { .compatible = "qcom,shikra", .data = &no_ubwc_data, },
qcm2290_data
> { .compatible = "qcom,sm4250", .data = &sm6115_data, },
> { .compatible = "qcom,sm6115", .data = &sm6115_data, },
> { .compatible = "qcom,sm6125", .data = &sm6125_data, },
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* ❌ FAIL: Test report for for-kernelci (7.1.0-rc6, upstream-arm-next, ec7ef10b)
From: cki-project @ 2026-06-04 0:03 UTC (permalink / raw)
To: yoyang, linux-arm-kernel, catalin.marinas, will
Hi, we tested your kernel and here are the results:
Overall result: FAILED
Merge: OK
Compile: OK
Test: FAILED
Kernel information:
Commit message: Merge branch 'for-next/core' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2574758120
One or more kernel tests failed:
Unrecognized or new issues:
xfstests - btrfs
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2574758120_aarch64_kernel_kcidb_tool_21407599_9
Non-passing ran subtests:
❌ FAIL generic/301
We also see the following known issues which are not related to your changes:
Issue: [upstream] Hardware - Firmware test suite - auto-waive failures
URL: https://gitlab.com/cki-project/infrastructure/-/issues/779
Affected tests:
Hardware - Firmware test suite [aarch64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v1 2/2] soc: aspeed: add host-side PCIe BMC device driver
From: Andrew Jeffery @ 2026-06-04 0:44 UTC (permalink / raw)
To: Andrew Lunn, Grégoire Layet
Cc: joel, jacky_chou, yh_chung, ninad, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <77464543-f793-4441-9fce-8666ba1c3d66@lunn.ch>
On Wed, 2026-06-03 at 16:30 +0200, Andrew Lunn wrote:
> On Wed, Jun 03, 2026 at 03:43:36PM +0200, Grégoire Layet wrote:
> > > How virtual is this? Is this directly accessing the hardware via
> > > shared memory? Or is there software on the BMC which traps these
> > > reads/writes and responds?
> >
> > The VUART is virtual because there is no physical UART link between
> > the host and the BMC.
> > Instead, the AST2600 exposes a 16550-compatible register set on both
> > sides (BMC APB and PCIe host MMIO).
> > The data flows using an internal 16 byte FIFO shared between the two
> > register views.
> > So it's hardware emulated and there is no software in the data path.
> >
> > The AST2600 has four VUARTs, two of which are accessible via PCIe MMIO.
> > This is based on the following section of the AST2600 datasheet:
> > III.48 VUART and III.64 PCI2VUART.
> >
> > Because the silicon presents a standard 16550A interface in hardware,
> > the existing 8250 driver works without modification.
>
> So tell us about security.
>
> Is only this UART exposed in the shared memory?
>
No, however the BMC PCI interface provides a PCI-to-LPC bridge, so PCI
accesses can drive cycles in to e.g LPC IO devices exposed by the BMC.
> So the memory window
> is 8 bytes wide? Or are there other peripherals also exposed? How do
> we know the aspeed is not using the UART itself?
>
For the "regular" SuperIO-controlled UARTs this is a concern, but it's
not a concern for the VUARTs. Each VUART has a pair of 8250 register
sets, one accessible from the BMC, the other accessible to the host,
where both interfaces share the FIFOs to propagate data.
> If two drivers are
> using it, are we going to crash one or the other system?
By the above, not for the VUARTs.
>
> https://en.wikipedia.org/wiki/Core_War
>
> The advantage of rpmsg is that the aspeed would advertise what
> services it is willing to expose. The security issues are different,
> implementation bugs vs exposing bits of hardware to an attacker.
From my understanding rpmsg seems like a reasonable fit for the mailbox
functionality.
Andrew
^ permalink raw reply
* Re: [PATCH v1 2/2] soc: aspeed: add host-side PCIe BMC device driver
From: Andrew Jeffery @ 2026-06-04 0:46 UTC (permalink / raw)
To: Grégoire Layet, Andrew Lunn
Cc: joel, jacky_chou, yh_chung, ninad, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAFi2wKY7ECbxSbtsO1W9KEKFET67yKg+C64jtQHFY05DRzhfKg@mail.gmail.com>
On Wed, 2026-06-03 at 15:43 +0200, Grégoire Layet wrote:
>
> For the rest of the driver (shared memory, doorbell and mailbox), you are right,
> it makes more sense to implement rpmsg or virtio than just raw shared
> memory binding.
> These are software-defined communication channels and not hardware-emulated,
> so they would fit better as rpmsg or virtio drivers.
> I took the SDK driver as a starting point without questioning its structure.
> I have verified the VUART was working correctly with the shared
> memory, doorbell and mailbox setup removed.
> I can split this into VUART only and defer the rest for a separate
> rpmsg/virtio work.
>
> So I propose for v2:
> - Remove the shared memory device, the sysfs doorbell and the mailbox
> from this series.
> - Retain only the required configuration and initialisation on the BMC
> side driver.
> This should mainly be SCU and PCIe device configuration but other
> initialisation will be reviewed to determine what is required.
> - The shared memory, doorbell and mailbox features could then be
> addressed in a separate future series, likely as virtio based driver.
>
> Would that be acceptable?
That sounds good to me.
From a brief inspection the driver also had support for both the 2600
and 2700. Something to consider is just supporting one of those for
now, and adding support for the other in later patches.
Andrew
^ permalink raw reply
* [PATCH 0/2] watchdog: sama5d4: fix IRQ and timeout bugs, use platform_get_irq_optional
From: Rosen Penev @ 2026-06-04 1:05 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
This series fixes three pre-existing issues in the sama5d4 watchdog
driver (unsafe IRQF_SHARED, incorrect IRQ_HANDLED return, ignored
device-tree timeout), then simplifies interrupt acquisition by
switching from irq_of_parse_and_map() to platform_get_irq_optional().
Rosen Penev (2):
watchdog: sama5d4: fix shared IRQ and hardcoded timeout issues
watchdog: sama5d4: use platform_get_irq_optional()
drivers/watchdog/sama5d4_wdt.c | 33 ++++++++++++++++++---------------
1 file changed, 18 insertions(+), 15 deletions(-)
--
2.54.0
^ 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