* Re: [RFC PATCH 1/2] KVM: arm64: Introduce S2 walker SKIP return options
From: Leonardo Bras @ 2026-05-18 13:45 UTC (permalink / raw)
To: Will Deacon
Cc: Leonardo Bras, Oliver Upton, Marc Zyngier, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Fuad Tabba,
Raghavendra Rao Ananta, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <agrTQMw4QJX6HGrm@willie-the-truck>
Hello Oliver, Will,
Thanks for reviewing!
On Mon, May 18, 2026 at 09:52:16AM +0100, Will Deacon wrote:
> On Mon, May 18, 2026 at 12:22:47AM -0700, Oliver Upton wrote:
> > On Fri, May 15, 2026 at 08:59:02PM +0100, Leonardo Bras wrote:
> > > Introduce S2 walker return values:
> > > - SKIP_CHILDREN: skip walking the children of the current node
> > > - SKIP_SIBLINGS: skip waling the siblings of the current node
> > >
> > > Also, modify __kvm_pgtable_visit() to fulfil the hing on above return
> > > values. Current walkers should not be impacted
> >
> > I'd rather see something based around new walk flags than introducing an
> > entirely new mechanic around return values.
> >
> > e.g. you could split the LEAF flag into separate flags for blocks v.
> > pages:
> >
> > KVM_PGTABLE_WALK_PAGE,
> > KVM_PGTABLE_WALK_BLOCK,
> > KVM_PGTABLE_WALK_LEAF = KVM_PGTABLE_WALK_PAGE |
> > KVM_PGTABLE_WALK_BLOCK,
> >
> > and then let __kvm_pgtable_visit() decide how to steer the walk. You may
> > need some special handling to get the address arithmetic right when
> > skipping over a table of page descriptors.
I am probably not getting the whole inner workings of this solution, but
IIUC the idea would be to walk the blocks, but not the pages, right?
Blocks meaning level2- and pages being level3?
> I was wondering along similar lines, but maybe it would be useful just
> to pass a maximum level to the walker logic? That feels like the most
> general case without complicating the existing logic.
This proposal seems simpler for me to understand, and indeed looks like a
better solution than what I have proposed, taking care of the
'already split' case with better performance, as it don't even walk a
single level-3 entry.
On the 'splitting' case, it also works flawlessly if the memory is given in
level-2 blocks. There is only one case that I would like to address here:
- Memory given in level-1 blocks (say 1GB)
- Walker flag says 'walk down to level-2 only'
- Split Walker on level-1 will break page down to (up to) level-3 entries.
- Walker will continue to be called on level-2 entries, even though it's
not necessary.
To solve this, I would like to suggest a new flag, that skips a table
that has just been created. This could be easily implemented in
__kvm_page_visit() on top of the max level flags suggested.
enum kvm_pgtable_walk_flags {
[...]
KVM_PGTABLE_WALK_SKIP_LEVEL3 = BIT(7),
KVM_PGTABLE_WALK_SKIP_LEVEL2 = BIT(8),
KVM_PGTABLE_WALK_SKIP_LEVEL1 = BIT(9),
KVM_PGTABLE_WALK_SKIP_NEW_TABLE = BIT(10),
};
How does that sound?
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v3 0/2] arm_ffa, KVM: Fix FF-A emad offset calculations
From: Sudeep Holla @ 2026-05-18 13:45 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, Sudeep Holla, will, joey.gouly,
korneld, kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, vdonnefort,
yuzenghui
In-Reply-To: <20260513-ludicrous-beautiful-cuttlefish-34271d@sudeepholla>
On Wed, May 13, 2026 at 06:23:43PM +0100, Sudeep Holla wrote:
> On Tue, May 12, 2026 at 12:44:40PM +0000, Sebastian Ene wrote:
> > Hi all,
> >
> > This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations
> > and adds the necessary bounds checks for both the core FF-A driver and the pKVM
> > hypervisor.
> >
> > Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset
> > for the EMADs, leading to the assumption that they immediately follow the header.
> > However, from v1.1 onwards, the specification dictates using the `ep_mem_offset` field
> > to determine the start of the memory access array.
> >
> > The patches in this series address this by:
> > 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor
> > offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`.
> > It also introduces bounds checking against `max_fragsize`.
> > 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that
> > the descriptor strictly follows the header, aligning it with the driver behavior
> > and the FF-A specification, while also ensuring the offset falls within the mailbox
> > buffer bounds.
> >
>
> Looks good apart from the minor nits, but how do you plan to route these
> changes as they are dependent for functionality but not for the build IIUC.
>
You can add (with minor nit fixed) my
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
if it is routed via KVM or other tree.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] drm/mediatek: Convert legacy DRM logging to drm_* helpers in mtk_dsi.c
From: Chun-Kuang Hu @ 2026-05-18 13:39 UTC (permalink / raw)
To: Abhishek Rajput
Cc: chunkuang.hu, p.zabel, airlied, simona, matthias.bgg,
angelogioacchino.delregno, dri-devel, linux-mediatek,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260420052008.5417-1-abhiraj21put@gmail.com>
Hi, Abhishek:
Abhishek Rajput <abhiraj21put@gmail.com> 於 2026年4月20日週一 上午5:20寫道：
>
> Replace DRM_INFO(), DRM_WARN() and DRM_ERROR() calls in
> drivers/gpu/drm/mediatek/mtk_dsi.c with the corresponding
> drm_info(), drm_warn() and drm_err() helpers.
>
> The drm_*() logging helpers take a struct drm_device * argument,
> allowing the DRM core to prefix log messages with the correct device
> name and instance. This is required to correctly distinguish log
> messages on systems with multiple GPUs.
>
> This change aligns the radeon driver with the DRM TODO item:
> "Convert logging to drm_* functions with drm_device parameter".
Applied to mediatek-drm-next [1], thanks.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Abhishek Rajput <abhiraj21put@gmail.com>
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0e2bcd5f67b7..a67ad575f5f0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -510,6 +510,7 @@ static void mtk_dsi_config_vdo_timing_per_line_lp(struct mtk_dsi *dsi)
> u32 delta;
> struct mtk_phy_timing *timing = &dsi->phy_timing;
> struct videomode *vm = &dsi->vm;
> + struct drm_device *drm = dsi->bridge.dev;
>
> if (dsi->format == MIPI_DSI_FMT_RGB565)
> dsi_tmp_buf_bpp = 2;
> @@ -543,7 +544,7 @@ static void mtk_dsi_config_vdo_timing_per_line_lp(struct mtk_dsi *dsi)
> horizontal_backporch_byte /
> horizontal_front_back_byte;
> } else {
> - DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
> + drm_warn(drm, "HFP + HBP less than d-phy, FPS will under 60Hz\n");
> }
>
> if ((dsi->mode_flags & MIPI_DSI_HS_PKT_END_ALIGNED) &&
> @@ -623,12 +624,13 @@ static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> {
> s32 ret = 0;
> unsigned long jiffies = msecs_to_jiffies(timeout);
> + struct drm_device *drm = dsi->bridge.dev;
>
> ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> dsi->irq_data & irq_flag,
> jiffies);
> if (ret == 0) {
> - DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> + drm_warn(drm, "Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset_engine(dsi);
> @@ -663,9 +665,10 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> {
> mtk_dsi_irq_data_clear(dsi, irq_flag);
> mtk_dsi_set_cmd_mode(dsi);
> + struct drm_device *drm = dsi->bridge.dev;
>
> if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> - DRM_ERROR("failed to switch cmd mode\n");
> + drm_err(drm, "failed to switch cmd mode\n");
> return -ETIME;
> } else {
> return 0;
> @@ -849,11 +852,12 @@ static void mtk_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> struct drm_atomic_state *state)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> + struct drm_device *drm = bridge->dev;
> int ret;
>
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0)
> - DRM_ERROR("failed to power on dsi\n");
> + drm_err(drm, "failed to power on dsi\n");
> }
>
> static void mtk_dsi_bridge_atomic_post_disable(struct drm_bridge *bridge,
> @@ -916,7 +920,7 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> ret = drm_simple_encoder_init(drm, &dsi->encoder,
> DRM_MODE_ENCODER_DSI);
> if (ret) {
> - DRM_ERROR("Failed to encoder init to drm\n");
> + drm_err(drm, "Failed to encoder init to drm\n");
> return ret;
> }
>
> @@ -932,7 +936,7 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>
> dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> if (IS_ERR(dsi->connector)) {
> - DRM_ERROR("Unable to create bridge connector\n");
> + drm_err(drm, "Unable to create bridge connector\n");
> ret = PTR_ERR(dsi->connector);
> goto err_cleanup_encoder;
> }
> @@ -985,6 +989,7 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
> {
> struct mtk_dsi *dsi = host_to_dsi(host);
> struct device *dev = host->dev;
> + struct drm_device *drm = dsi->bridge.dev;
> int ret;
>
> dsi->lanes = device->lanes;
> @@ -1012,7 +1017,7 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
>
> ret = component_add(host->dev, &mtk_dsi_component_ops);
> if (ret) {
> - DRM_ERROR("failed to add dsi_host component: %d\n", ret);
> + drm_err(drm, "failed to add dsi_host component: %d\n", ret);
> drm_bridge_remove(&dsi->bridge);
> return ret;
> }
> @@ -1034,11 +1039,12 @@ static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> {
> int ret;
> u32 val;
> + struct drm_device *drm = dsi->bridge.dev;
>
> ret = readl_poll_timeout(dsi->regs + DSI_INTSTA, val, !(val & DSI_BUSY),
> 4, 2000000);
> if (ret) {
> - DRM_WARN("polling dsi wait not busy timeout!\n");
> + drm_warn(drm, "polling dsi wait not busy timeout!\n");
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset_engine(dsi);
> @@ -1123,6 +1129,7 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,
> const struct mipi_dsi_msg *msg)
> {
> struct mtk_dsi *dsi = host_to_dsi(host);
> + struct drm_device *drm = dsi->bridge.dev;
> ssize_t recv_cnt;
> u8 read_data[16];
> void *src_addr;
> @@ -1153,7 +1160,7 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,
> }
>
> if (!msg->rx_buf) {
> - DRM_ERROR("dsi receive buffer size may be NULL\n");
> + drm_err(drm, "dsi receive buffer size may be NULL\n");
> ret = -EINVAL;
> goto restore_dsi_mode;
> }
> @@ -1177,7 +1184,7 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,
> if (recv_cnt)
> memcpy(msg->rx_buf, src_addr, recv_cnt);
>
> - DRM_INFO("dsi get %zd byte data from the panel address(0x%x)\n",
> + drm_info(drm, "dsi get %zd byte data from the panel address(0x%x)\n",
> recv_cnt, *((u8 *)(msg->tx_buf)));
>
> restore_dsi_mode:
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Kohei Enju @ 2026-05-18 13:38 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Sami Mujawar, Gavin Shan, Steven Price,
Suzuki K Poulose, linux-arm-kernel, linux-kernel
In-Reply-To: <agsHBb9f3HkmJaIx@arm.com>
On 05/18 13:33, Catalin Marinas wrote:
> On Mon, May 18, 2026 at 12:31:31PM +0900, Kohei Enju wrote:
> > With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of
> > debug_smp_processor_id(). This debug function complains when certain
> > conditions that ensure CPU ID stability are not met, specifically when
> > it's called from a preemptible context.
> >
> > In arm_cca_report_new(), which runs in a preemptible context,
> > smp_processor_id() triggers a splat [0] due to this.
> >
> > However, the CPU ID obtained here is used as the target CPU for
> > smp_call_function_single() to designate a specific CPU for subsequent
> > operations, not to assert that the current thread will continue to
> > execute on the same CPU. Therefore, snapshotting the CPU ID itself is
> > correct, and thus there's no actual harm except for the splat.
> >
> > Use raw_smp_processor_id() instead, to directly retrieve the current CPU
> > ID without the debug checks, avoiding the unnecessary warning message
> > while preserving the correct functional behavior.
> >
> > [0]
> > BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/134
> > caller is debug_smp_processor_id+0x20/0x2c
> > CPU: 0 UID: 0 PID: 134 Comm: cca-workload-at Not tainted 7.0.0-rc1-gc74a64d12073 #1 PREEMPT
> > Hardware name: linux,dummy-virt (DT)
> > Call trace:
> > [...]
> > check_preemption_disabled+0xf8/0x100
> > debug_smp_processor_id+0x20/0x2c
> > arm_cca_report_new+0x54/0x230
> > tsm_report_read+0x184/0x260
> > tsm_report_outblob_read+0x18/0x38
> > configfs_bin_read_iter+0xf4/0x1dc
> > vfs_read+0x230/0x31c
> > [...]
> >
> > Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
> > Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
> > ---
> > drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > index 0c9ea24a200c..2d450caee3e4 100644
> > --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > @@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> > * allocate outblob based on the returned value from the 'init'
> > * call and that cannot be done in an atomic context.
> > */
> > - cpu = smp_processor_id();
> > + cpu = raw_smp_processor_id();
>
> That's just hiding the warning which might be genuine, irrespective of
> what the comment says. Sashiko has some good points:
>
> https://sashiko.dev/#/patchset/20260518033157.1865498-1-enju.kohei@fujitsu.com
>
> Basically what guarantees that the cpu won't go offline? Can we use
> migrate_disable() and ignore the smp_call_function_single() altogether?
> It looks like a hack anyway.
Hi Catalin,
Thank you for reviewing.
You've raised a very valid point about raw_smp_processor_id()
potentially hiding a genuine issue. I agree this would be a concern in
most contexts.
However, this implementation was intentionally designed not to block CPU
hotplug:
https://lore.kernel.org/linux-arm-kernel/7a83461d-40fd-4e61-8833-5dae2abaf82b@arm.com/
As mentioned in the thread above, the potential failure from the target
CPU going offline (resulting in -ENXIO) is an expected and tolerated
condition in this path.
Using migrate_disable() would go against the non-blocking design goal.
Given the context, the debug warning looks false positive for our
specific use case to me, and I believe raw_smp_processor_id() correctly
reflects the design intent by simply acquiring a CPU number without
debug checks.
>
> We should also look at the other unrelated findings in this function
Regarding the other unrelated findings by Sashiko, I'll take a look at
them. Thanks for the heads-up.
Thanks,
Kohei
>
> --
> Catalin
>
^ permalink raw reply
* [PATCH] media: stm32: dcmi: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 13:23 UTC (permalink / raw)
To: Hugues Fruchet, Alain Volmat, Mauro Carvalho Chehab,
Maxime Coquelin, Alexandre Torgue, Yannick Fertre, Hans Verkuil,
linux-media, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Guangshuo Li
dcmi_probe() allocates a video_device with video_device_alloc() and
releases it from the err_device_release error path if
video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
dcmi_probe()
-> err_device_release
-> video_device_release(dcmi->vdev)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free dcmi->vdev through vdev->release().
dcmi_probe() then releases dcmi->vdev exactly once from
err_device_release. Restore video_device_release() after successful
registration so the registered device keeps its normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 37404f91ef8b ("[media] stm32-dcmi: STM32 DCMI camera interface driver")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/st/stm32/stm32-dcmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/st/stm32/stm32-dcmi.c b/drivers/media/platform/st/stm32/stm32-dcmi.c
index 13762861b769..a6918fc618fb 100644
--- a/drivers/media/platform/st/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/st/stm32/stm32-dcmi.c
@@ -1990,7 +1990,7 @@ static int dcmi_probe(struct platform_device *pdev)
dcmi->vdev->v4l2_dev = &dcmi->v4l2_dev;
dcmi->vdev->queue = &dcmi->queue;
strscpy(dcmi->vdev->name, KBUILD_MODNAME, sizeof(dcmi->vdev->name));
- dcmi->vdev->release = video_device_release;
+ dcmi->vdev->release = video_device_release_empty;
dcmi->vdev->ioctl_ops = &dcmi_ioctl_ops;
dcmi->vdev->lock = &dcmi->lock;
dcmi->vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
@@ -2012,6 +2012,7 @@ static int dcmi_probe(struct platform_device *pdev)
dev_err(dcmi->dev, "Failed to register video device\n");
goto err_media_entity_cleanup;
}
+ dcmi->vdev->release = video_device_release;
dev_dbg(dcmi->dev, "Device registered as %s\n",
video_device_node_name(dcmi->vdev));
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 6/9] iommu/arm-smmu-v3: Directly encode simple commands
From: Jason Gunthorpe @ 2026-05-18 13:23 UTC (permalink / raw)
To: Nicolin Chen
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <agqETancvNtL0lXc@Asurada-Nvidia>
On Sun, May 17, 2026 at 08:15:25PM -0700, Nicolin Chen wrote:
> > +static inline struct arm_smmu_cmd arm_smmu_make_cmd_cfgi_all(void)
> > +{
> > + struct arm_smmu_cmd cmd = arm_smmu_make_cmd_op(CMDQ_OP_CFGI_ALL);
> > +
> > + cmd.data[1] |= FIELD_PREP(CMDQ_CFGI_1_RANGE, 31);
>
> Optional, might retain the note:
> /* Cover the entire SID range */
The spec doesn't have a note like this is just defined cfgi_all as
having this encoding.
Jason
^ permalink raw reply
* Re: [PATCH v8 2/4] firmware: ti_sci: add support for restoring IRQs during resume
From: Kumar, Udit @ 2026-05-18 13:22 UTC (permalink / raw)
To: Thomas Richard (TI), Nishanth Menon, Tero Kristo,
Santosh Shilimkar, Michael Turquette, Stephen Boyd, Brian Masney
Cc: Gregory CLEMENT, richard.genoud, Abhash Kumar, Thomas Petazzoni,
linux-arm-kernel, linux-kernel, linux-clk, Dhruva Gole,
Kendall Willis, u-kumar1
In-Reply-To: <20260513-ti-sci-jacinto-s2r-restore-irq-v8-2-195b27f91519@bootlin.com>
On 5/13/2026 6:16 PM, Thomas Richard (TI) wrote:
> Some DM-Firmware are not able to restore the IRQ context after a
> suspend-resume. The IRQ_CONTEXT_LOST firmware capability has been
> introduced to identify this characteristic. In this case the
> responsibility is delegated to the ti_sci driver, which maintains an
> internal list of all requested IRQs. This list is updated on each
> set()/free() operation, and all IRQs are restored during the resume_noirq()
> phase.
>
> Reviewed-by: Dhruva Gole <d-gole@ti.com>
> Reviewed-by: Kendall Willis <k-willis@ti.com>
> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
> ---
> drivers/firmware/ti_sci.c | 201 +++++++++++++++++++++++++++++++++++++++++++---
> drivers/firmware/ti_sci.h | 3 +
> 2 files changed, 192 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index eaeaaae94142..35ee8cc830c8 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -12,11 +12,13 @@
> #include <linux/cpu.h>
> #include <linux/debugfs.h>
> #include <linux/export.h>
> +#include <linux/hashtable.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> #include <linux/kernel.h>
> #include <linux/mailbox_client.h>
> #include <linux/module.h>
> +#include <linux/mutex.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
Could you check, recursive header inclusion header warning
In file included from linux/printk.h,
from linux/srcu.h:85
from linux/notifier.h:16
from linux/reboot.h:6
-drivers/firmware/ti_sci.c:31: warning: recursive header inclusion
+drivers/firmware/ti_sci.c:33: warning: recursive header inclusion
> @@ -87,6 +89,16 @@ struct ti_sci_desc {
> int max_msg_size;
> };
>
> +/**
> + * struct ti_sci_irq - Description of allocated irqs
> + * @node: Link to hash table
> + * @desc: Description of the irq
> + */
> +struct ti_sci_irq {
> + struct hlist_node node;
> + struct ti_sci_msg_req_manage_irq desc;
> +};
> +
> /**
> * struct ti_sci_info - Structure representing a TI SCI instance
> * @dev: Device pointer
> @@ -101,6 +113,8 @@ struct ti_sci_desc {
> * @chan_rx: Receive mailbox channel
> * @minfo: Message info
> * @node: list head
> + * @irqs: List of allocated irqs
> + * @irq_lock: Protection for irq hash list
> * @host_id: Host ID
> * @fw_caps: FW/SoC low power capabilities
> * @users: Number of users of this instance
> @@ -118,6 +132,8 @@ struct ti_sci_info {
> struct mbox_chan *chan_rx;
> struct ti_sci_xfers_info minfo;
> struct list_head node;
> + DECLARE_HASHTABLE(irqs, 8);
> + struct mutex irq_lock;
One of script report errors, you might need to document hashtabke.
However warning is unrelated
CHECK: struct mutex definition without commen
> u8 host_id;
> u64 fw_caps;
> /* protected by ti_sci_list_mutex */
> @@ -2301,6 +2317,32 @@ static int ti_sci_manage_irq(const struct ti_sci_handle *handle,
> return ret;
> }
>
[..]
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: g6: Add PWM/Tach controller node
From: Andrew Jeffery @ 2026-05-18 13:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Billy Tsai
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260326-g6-dtsi-v1-1-348e7a0661c2@aspeedtech.com>
On Thu, 26 Mar 2026 18:29:22 +0800, Billy Tsai wrote:
> Introduce a device tree node for the AST2600 PWM/Tach controller.
> Describe register range, clock, reset, and cell configuration.
> Set status to "disabled" by default.
>
> Prepares for enabling PWM and tachometer support on platforms
> utilizing this SoC.
>
> [...]
Thanks, I've applied this to the BMC tree.
--
Andrew Jeffery <andrew@codeconstruct.com.au>
^ permalink raw reply
* Re: [PATCH v4 2/3] arm64: dts: ti: Add k3-am62l3-beaglebadge
From: Nishanth Menon @ 2026-05-18 13:11 UTC (permalink / raw)
To: Judith Mendez
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel, Andrew Davis, Bryan Brattlof, Jason Kridner,
Robert Nelson
In-Reply-To: <20260515153541.294698-3-jm@ti.com>
On 10:35-20260515, Judith Mendez wrote:
> BeagleBoard.org BeagleBadge is a compact, affordable open source
> hardware single board computer based on the Texas Instruments AM62L3
> SoC designed for IoT and embedded applications with low power
> consumption. Expansion is provided over open standards based headers
> including QWIIC and GPIO interfaces.
>
> https://github.com/beagleboard/BeagleBadge
Why not use https://www.beagleboard.org/boards/beaglebadge ?
>
> Co-developed-by: Andrew Davis <afd@ti.com>
> Signed-off-by: Andrew Davis <afd@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
> Changelog since v3:
> - Add missing newline in commit message
> - Drop beagleboard URL
> - Drop uneeded header files
> - Add boothph flags in wkup_i2c0 & PMC nodes
> ---
> arch/arm64/boot/dts/ti/Makefile | 1 +
> .../boot/dts/ti/k3-am62l3-beaglebadge.dts | 700 ++++++++++++++++++
> 2 files changed, 701 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
>
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 5269c9619b65c..4e377ca011cd8 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62d2-evm.dtb
>
> # Boards with AM62Lx SoCs
> dtb-$(CONFIG_ARCH_K3) += k3-am62l3-evm.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-am62l3-beaglebadge.dtb
>
> # Boards with AM62Px SoC
> dtb-$(CONFIG_ARCH_K3) += k3-am62p5-sk.dtb
> diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
> new file mode 100644
> index 0000000000000..30fc9c83b1f44
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
> @@ -0,0 +1,700 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * https://www.beagleboard.org/boards/beaglebadge
> + *
> + * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
Seeing the tags, I assume no BeagleBoard.org member contributions?
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> +#include "k3-am62l3.dtsi"
> +#include "k3-pinctrl.h"
> +
> +/ {
> + compatible = "beagle,am62l3-beaglebadge", "ti,am62l3";
> + model = "BeagleBoard.org BeagleBadge";
> +
> + chosen {
> + stdout-path = &uart0;
> + };
> +
> + aliases {
> + gpio0 = &gpio0;
> + gpio2 = &wkup_gpio0;
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + i2c4 = &wkup_i2c0;
> + mmc1 = &sdhci1;
> + mmc2 = &sdhci2;
> + serial3 = &uart1;
> + usb0 = &usb0;
> + usb1 = &usb1;
is this valid?
git grep of_alias_ driver/usb/
am I missing something?
> + };
> +
> + memory@80000000 {
> + /* 256MB */
> + reg = <0x00000000 0x80000000 0x00000000 0x10000000>;
> + device_type = "memory";
> + bootph-all;
> + };
> +
> + thermal-zones {
> + wkup0-thermal {
> + polling-delay-passive = <250>; /* milliSeconds */
> + polling-delay = <500>; /* milliSeconds */
> + thermal-sensors = <&vtm0 0>;
> +
> + trips {
> + crit0 {
> + temperature = <125000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
This is better done by having something like
arch/arm64/boot/dts/ti/k3-am62l-industrial-thermal.dtsi
[..]
> +
> + sensor_3v3: regulator-4 {
> + /* TPS22918DBVR */
> + compatible = "regulator-fixed";
> + regulator-name = "Sensor_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vdd_3v3>;
> + regulator-boot-on;
> + regulator-always-on;
Why sensor supply is always on?
> + enable-active-high;
> + gpio = <&wkup_gpio0 1 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sensor_3v3_ena_pins_default>;
> + bootph-all;
> + };
> +
> + wlan_en: regulator-5 {
> + compatible = "regulator-fixed";
> + regulator-name = "wlan_en";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + enable-active-high;
> + gpios = <&gpio0 51 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&wlan_en_pins_default>;
> + };
> +};
> +
[..]
> +
> + usr_button_pins_default: usr-button-default-pins {
> + pinctrl-single,pins = <
> + AM62LX_IOPAD(0x00a4, PIN_INPUT, 7) /* (H18) GPMC0_AD11.GPIO0_26 */
> + AM62LX_IOPAD(0x01e4, PIN_INPUT, 7) /* (D16) EXT_REFCLK1.GPIO0_104 */
> + AM62LX_IOPAD(0x00c0, PIN_INPUT, 7) /* (N19) GPMC0_ADVn_ALE.GPIO0_32 */
> + AM62LX_IOPAD(0x00e8, PIN_INPUT, 7) /* (L19) GPMC0_CSn1.GPIO0_42 */
> + AM62LX_IOPAD(0x00b8, PIN_INPUT, 7) /* (L21) GPMC0_CLK.GPIO0_31 */
> + AM62LX_IOPAD(0x01c0, PIN_INPUT, 7) /* (B13) UART0_RTSn.GPIO0_95 */
> + >;
> + };
no wakeup from usr buttons?
[...]
> +};
> +
> +&gpio0 {
> + gpio-line-names ="","","","","","","","","","", /* 0-9 */
space after that =
> + "","","","","","BOOST_5V_ENA","VDD_3V3_SD_ENA","","","", /* 10-19 */
> + "","","","","","MCP23S18_RESET","BTN_SELECT","","","", /* 20-29 */
> + "","BTN_LEFT","BTN_UP","","LORA_RESET","","","","","", /* 30-39 */
> + "FUEL_GAUGE_BATLOW","LORA_RFSW","BTN_DOWN","USB_HUB_RST","MIKROBUS_INT","","","","","", /* 40-49 */
> + "","WLAN_EN","","","","","","","","", /* 50-59 */
> + "","","","","","","","","","", /* 60-69 */
> + "","","","","","","","","","", /* 70-79 */
> + "","","","","MIKROBUS_RST","","","","LORA_BUSY","", /* 80-89 */
> + "","","","","LORA_DIO","BTN_RIGHT","","","","", /* 90-99 */
> + "","","","","BTN_BACK","","","","","", /* 100-109 */
> + "","","","","","","","","","", /* 110-119 */
> + "","","SD_CD","","",""; /* 120-125 */
Could you keep these under 100 chars?
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio0_pins_default>, <&usr_button_pins_default>, <&lora_control_pins_default>;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&wkup_gpio0 {
> + gpio-line-names ="","SENSOR_3V3_ENA","","","","","",""; /* 0-7 */
same
> + bootph-all;
> + status = "okay";
> +};
> +
> +&sdhci1 {
> + /* SD/MMC */
> + vmmc-supply = <&vdd_3v3_sd>;
> + disable-wp;
> + cd-gpios = <&gpio0 122 GPIO_ACTIVE_LOW>;
> + cd-debounce-delay-ms = <100>;
> + ti,fails-without-test-cd;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins_default>;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&sdhci2 {
> + vmmc-supply = <&wlan_en>;
> + bus-width = <4>;
> + non-removable;
> + cap-power-off-card;
> + keep-power-in-suspend;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_pins_default>;
> + ti,driver-strength-ohm = <50>;
> + ti,fails-without-test-cd;
> + status = "okay";
> +};
Why not introduce the sdhci2 and supplies once we get wlan driver in
upstream?
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* [PATCH] media: s5p-mfc: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 13:09 UTC (permalink / raw)
To: Marek Szyprowski, Andrzej Hajda, Mauro Carvalho Chehab,
Joonyoung Shim, Kamil Debski, linux-arm-kernel, linux-media,
linux-kernel
Cc: Guangshuo Li
s5p_mfc_probe() allocates video_device instances for both the decoder
and encoder and releases them from the probe error paths if
video_register_device() fails.
This can double free a video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
s5p_mfc_probe()
-> err_dec_reg or err_enc_reg
-> video_device_release(vdev)
Use video_device_release_empty() while registering the decoder and encoder
video devices so that registration failure paths do not free them through
vdev->release(). s5p_mfc_probe() then releases each video_device exactly
once from its error path. Restore video_device_release() after successful
registration so the registered devices keep their normal lifetime
handling.
This issue was found by a static analysis tool I am developing.
Fixes: d0ce898c39bf ("[media] s5p-mfc: Replaced commas with semicolons")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index 32eb402d439c..75abb0a8b7a9 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -1376,7 +1376,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
}
vfd->fops = &s5p_mfc_fops;
vfd->ioctl_ops = get_dec_v4l2_ioctl_ops();
- vfd->release = video_device_release;
+ vfd->release = video_device_release_empty;
vfd->lock = &dev->mfc_mutex;
vfd->v4l2_dev = &dev->v4l2_dev;
vfd->vfl_dir = VFL_DIR_M2M;
@@ -1395,7 +1395,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
}
vfd->fops = &s5p_mfc_fops;
vfd->ioctl_ops = get_enc_v4l2_ioctl_ops();
- vfd->release = video_device_release;
+ vfd->release = video_device_release_empty;
vfd->lock = &dev->mfc_mutex;
vfd->v4l2_dev = &dev->v4l2_dev;
vfd->vfl_dir = VFL_DIR_M2M;
@@ -1416,6 +1416,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
goto err_dec_reg;
}
+
+ dev->vfd_dec->release = video_device_release;
v4l2_info(&dev->v4l2_dev,
"decoder registered as /dev/video%d\n", dev->vfd_dec->num);
@@ -1424,6 +1426,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
goto err_enc_reg;
}
+
+ dev->vfd_enc->release = video_device_release;
v4l2_info(&dev->v4l2_dev,
"encoder registered as /dev/video%d\n", dev->vfd_enc->num);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed: anacapa: Enable MCTP and FRU for NIC
From: Andrew Jeffery @ 2026-05-18 13:09 UTC (permalink / raw)
To: Andy.Chung, Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260327-dts_enable_nic_mctp-v1-1-5b5c05f4442c@amd.com>
Hi Andy,
Sorry for the delay.
On Fri, 2026-03-27 at 14:59 +0800, Andy Chung via B4 Relay wrote:
> From: Andy Chung <Andy.Chung@amd.com>
>
> Add the mctp-controller property to enable frontend NIC management
> via PLDM over MCTP.
> Also add EEPROM device for NIC FRU.
>
> Signed-off-by: Andy Chung <Andy.Chung@amd.com>
> ---
> Add the mctp-controller property to enable frontend NIC management
> via PLDM over MCTP.
> Also add EEPROM device for NIC FRU.
> ---
> .../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 67 +++++++++++++++++++++-
> 1 file changed, 65 insertions(+), 2 deletions(-)
Do you mind coordinating with Colin on this one, as he's rearranging
the Anacapa devicetrees.
Cheers,
Andrew
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
> index 221af858cb6b..138b081be049 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
> @@ -584,38 +584,67 @@ eeprom@56 {
> // R Bridge Board
> &i2c10 {
> status = "okay";
> + multi-master;
> + mctp@10 {
> + compatible = "mctp-i2c-controller";
> + reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
> + };
>
> i2c-mux@71 {
> compatible = "nxp,pca9548";
> reg = <0x71>;
> #address-cells = <1>;
> #size-cells = <0>;
> - i2c-mux-idle-disconnect;
>
> i2c10mux0ch0: i2c@0 {
> reg = <0>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> };
> i2c10mux0ch1: i2c@1 {
> reg = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c10mux0ch2: i2c@2 {
> reg = <2>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c10mux0ch3: i2c@3 {
> reg = <3>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c10mux0ch4: i2c@4 {
> reg = <4>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c10mux0ch5: i2c@5 {
> reg = <5>;
> @@ -661,38 +690,72 @@ i2c10mux0ch7: i2c@7 {
> // L Bridge Board
> &i2c11 {
> status = "okay";
> + multi-master;
> + mctp@10 {
> + compatible = "mctp-i2c-controller";
> + reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
> + };
>
> i2c-mux@71 {
> compatible = "nxp,pca9548";
> reg = <0x71>;
> #address-cells = <1>;
> #size-cells = <0>;
> - i2c-mux-idle-disconnect;
>
> i2c11mux0ch0: i2c@0 {
> reg = <0>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // FE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c11mux0ch1: i2c@1 {
> reg = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c11mux0ch2: i2c@2 {
> reg = <2>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c11mux0ch3: i2c@3 {
> reg = <3>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c11mux0ch4: i2c@4 {
> reg = <4>;
> #address-cells = <1>;
> #size-cells = <0>;
> + mctp-controller;
> + // BE NIC FRU
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> };
> i2c11mux0ch5: i2c@5 {
> reg = <5>;
>
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20260327-dts_enable_nic_mctp-e35a5765b176
>
> Best regards,
> --
> Andy Chung <Andy.Chung@amd.com>
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: g6: Add missing uart nodes
From: Andrew Jeffery @ 2026-05-18 13:04 UTC (permalink / raw)
To: Jammy Huang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260327-upstream_g6_dts_uart-v1-1-26e72b47bc97@aspeedtech.com>
Hi Jammy,
Sorry for the delay.
On Fri, 2026-03-27 at 09:58 +0800, Jammy Huang wrote:
> Add nodes for uart10/11/12/13.
>
> Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 56 +++++++++++++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
Do you mind rebasing this on bmc/linux.git aspeed/arm/dt to fix the
conflict and re-sending it?
Cheers,
Andrew
^ permalink raw reply
* [PATCH] media: imx-jpeg: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 13:02 UTC (permalink / raw)
To: Mirela Rabulea, Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Hans Verkuil, imx,
linux-media, linux-arm-kernel, linux-kernel
Cc: Guangshuo Li
mxc_jpeg_probe() allocates a video_device with video_device_alloc() and
releases it from the err_vdev_register error path if
video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
mxc_jpeg_probe()
-> err_vdev_register
-> video_device_release(jpeg->dec_vdev)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free jpeg->dec_vdev through
vdev->release(). mxc_jpeg_probe() then releases jpeg->dec_vdev exactly
once from err_vdev_register. Restore video_device_release() after
successful registration so the registered device keeps its normal lifetime
handling.
This issue was found by a static analysis tool I am developing.
Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
index b442dcba02e7..fe8a373576ef 100644
--- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
+++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
@@ -2943,7 +2943,7 @@ static int mxc_jpeg_probe(struct platform_device *pdev)
jpeg->dec_vdev->fops = &mxc_jpeg_fops;
jpeg->dec_vdev->ioctl_ops = &mxc_jpeg_ioctl_ops;
jpeg->dec_vdev->minor = -1;
- jpeg->dec_vdev->release = video_device_release;
+ jpeg->dec_vdev->release = video_device_release_empty;
jpeg->dec_vdev->lock = &jpeg->lock; /* lock for ioctl serialization */
jpeg->dec_vdev->v4l2_dev = &jpeg->v4l2_dev;
jpeg->dec_vdev->vfl_dir = VFL_DIR_M2M;
@@ -2962,6 +2962,8 @@ static int mxc_jpeg_probe(struct platform_device *pdev)
dev_err(dev, "failed to register video device\n");
goto err_vdev_register;
}
+ jpeg->dec_vdev->release = video_device_release;
+
if (mode == MXC_JPEG_ENCODE)
v4l2_info(&jpeg->v4l2_dev,
"encoder device registered as /dev/video%d (%d,%d)\n",
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH v4 00/14] coco/TSM: Host-side Arm CCA IDE setup via connect/disconnect callbacks
From: Will Deacon @ 2026-05-18 12:59 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-coco, kvmarm, linux-arm-kernel, linux-kernel,
Alexey Kardashevskiy, Catalin Marinas, Dan Williams,
Jason Gunthorpe, Jonathan Cameron, Marc Zyngier, Samuel Ortiz,
Steven Price, Suzuki K Poulose, Xu Yilun
In-Reply-To: <20260427065121.916615-1-aneesh.kumar@kernel.org>
On Mon, Apr 27, 2026 at 12:21:07PM +0530, Aneesh Kumar K.V (Arm) wrote:
> arch/arm64/include/asm/rmi_cmds.h | 85 +++
> arch/arm64/include/asm/rmi_smc.h | 168 +++++
Curious, but why does this stuff have to live in the arch code? Wouldn't
it be better off somewhere like drivers/firmware/ or
include/linux/arm-rmi.h?
Will
^ permalink raw reply
* Re: [PATCH v12 06/15] kasan: arm64: x86: Make page_to_virt() KASAN aware
From: Maciej Wieczor-Retman @ 2026-05-18 12:59 UTC (permalink / raw)
To: Will Deacon
Cc: Maciej Wieczor-Retman, Catalin Marinas, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, linux-arm-kernel, linux-kernel,
kasan-dev, linux-mm
In-Reply-To: <agr-g38q5RiahqaA@willie-the-truck>
On 2026-05-18 at 12:56:51 +0100, Will Deacon wrote:
>On Mon, Mar 30, 2026 at 02:33:43PM +0000, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 875c0bd0d85a..39dd0071d3ec 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -411,11 +411,6 @@ static inline unsigned long virt_to_pfn(const void *kaddr)
>> */
>>
>> #if defined(CONFIG_DEBUG_VIRTUAL)
>> -#define page_to_virt(x) ({ \
>> - __typeof__(x) __page = x; \
>> - void *__addr = __va(page_to_phys(__page)); \
>> - (void *)__tag_set((const void *)__addr, page_kasan_tag(__page));\
>> -})
>
>So here we're using '__page' to avoid multiple evaluations of 'x'...
>
...
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 09044934dda8..f234650a4edf 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -117,7 +117,10 @@ extern int mmap_rnd_compat_bits __read_mostly;
>> #endif
>>
>> #ifndef page_to_virt
>> -#define page_to_virt(x) __va(PFN_PHYS(page_to_pfn(x)))
>> +#define page_to_virt(x) ({ \
>> + void *__addr = __va(PFN_PHYS(page_to_pfn((struct page *)x))); \
>> + kasan_set_tag(__addr, page_kasan_tag(x)); \
>> +})
>
>... but in the new code you're proposing, you evaluate 'x' twice.
>
>Is there a reason not to take the arm64 code as-is?
>
>Will
I was going for less lines in this macro when I initially wrote it. But you're
right, the arm64 version is better, I'll switch to it.
Thanks!
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* Re: [PATCH] PCI: meson: Propagate devm_add_action_or_reset() failure
From: Neil Armstrong @ 2026-05-18 12:56 UTC (permalink / raw)
To: Shuvam Pandey, Yue Wang,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: linux-pci, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <177909148011.9588.6639767953842842291@gmail.com>
On 5/18/26 10:04, Shuvam Pandey wrote:
> meson_pcie_probe_clock() enables a clock and then registers a devres
> action to disable it during teardown. If devm_add_action_or_reset()
> fails, it runs the action immediately, disabling the clock.
>
> The return value is currently ignored, so on that failure path
> meson_pcie_probe_clock() returns the disabled clock and probe continues.
> Return the error so the existing probe error path unwinds normally.
>
> Fixes: 9c0ef6d34fdbf ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
> Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
> ---
> drivers/pci/controller/dwc/pci-meson.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
> index 0694084f612b..8d495bcc3a41 100644
> --- a/drivers/pci/controller/dwc/pci-meson.c
> +++ b/drivers/pci/controller/dwc/pci-meson.c
> @@ -204,7 +204,9 @@ static inline struct clk *meson_pcie_probe_clock(struct device *dev,
> return ERR_PTR(ret);
> }
>
> - devm_add_action_or_reset(dev, meson_pcie_disable_clock, clk);
> + ret = devm_add_action_or_reset(dev, meson_pcie_disable_clock, clk);
> + if (ret)
> + return ERR_PTR(ret);
>
> return clk;
> }
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* [PATCH] media: mediatek: mdp: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 12:55 UTC (permalink / raw)
To: Minghsiu Tsai, Houlong Wei, Andrew-CT Chen, Mauro Carvalho Chehab,
Matthias Brugger, AngeloGioacchino Del Regno, Hans Verkuil,
linux-media, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Guangshuo Li
mtk_mdp_register_m2m_device() allocates a video_device with
video_device_alloc() and releases it from the err_m2m_init error path if
video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
mtk_mdp_register_m2m_device()
-> err_m2m_init
-> video_device_release(mdp->vdev)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free mdp->vdev through vdev->release().
mtk_mdp_register_m2m_device() then releases mdp->vdev exactly once from
err_m2m_init. Restore video_device_release() after successful registration
so the registered device keeps its normal lifetime handling.
Clear mdp->vdev after releasing it on failure to avoid leaving a stale
pointer behind.
This issue was found by a static analysis tool I am developing.
Fixes: 7febb418a32a ("[media] mtk-mdp: allocate video_device dynamically")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c b/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
index d2813890cceb..5cc80a542eda 100644
--- a/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
@@ -1185,7 +1185,7 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
mdp->vdev->fops = &mtk_mdp_m2m_fops;
mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
- mdp->vdev->release = video_device_release;
+ mdp->vdev->release = video_device_release_empty;
mdp->vdev->lock = &mdp->lock;
mdp->vdev->vfl_dir = VFL_DIR_M2M;
mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
@@ -1205,6 +1205,7 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
dev_err(dev, "failed to register video device\n");
goto err_vdev_register;
}
+ mdp->vdev->release = video_device_release;
v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
mdp->vdev->num);
@@ -1213,7 +1214,8 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
err_vdev_register:
v4l2_m2m_release(mdp->m2m_dev);
err_m2m_init:
- video_device_release(mdp->vdev);
+ video_device_release(mdp->vdev)
+ mdp->vdev = NULL;
err_video_alloc:
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH] media: mediatek: jpeg: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 12:51 UTC (permalink / raw)
To: Bin Liu, Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, Tomasz Figa, Hans Verkuil, Xia Jiang,
linux-media, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Guangshuo Li
mtk_jpeg_probe() allocates a video_device with video_device_alloc() and
releases it from the err_vfd_jpeg_register error path if
video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
mtk_jpeg_probe()
-> err_vfd_jpeg_register
-> video_device_release(jpeg->vdev)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free jpeg->vdev through vdev->release().
mtk_jpeg_probe() then releases jpeg->vdev exactly once from
err_vfd_jpeg_register. Restore video_device_release() after successful
registration so the registered device keeps its normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 2ac8015f156b ("media: platform: Rename existing functions/defines/variables")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index c01124a349f6..9888ac8dd6e4 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1362,7 +1362,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
jpeg->vdev->fops = &mtk_jpeg_fops;
jpeg->vdev->ioctl_ops = jpeg->variant->ioctl_ops;
jpeg->vdev->minor = -1;
- jpeg->vdev->release = video_device_release;
+ jpeg->vdev->release = video_device_release_empty;
jpeg->vdev->lock = &jpeg->lock;
jpeg->vdev->v4l2_dev = &jpeg->v4l2_dev;
jpeg->vdev->vfl_dir = VFL_DIR_M2M;
@@ -1374,6 +1374,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
v4l2_err(&jpeg->v4l2_dev, "Failed to register video device\n");
goto err_vfd_jpeg_register;
}
+ jpeg->vdev->release = video_device_release;
video_set_drvdata(jpeg->vdev, jpeg);
v4l2_info(&jpeg->v4l2_dev,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Andre Przywara @ 2026-05-18 12:50 UTC (permalink / raw)
To: Alexander Sverdlin, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <6d8659f393e0bb4f0805107a17e306422982247c.camel@gmail.com>
Hi,
On 5/18/26 13:29, Alexander Sverdlin wrote:
> Hi Andre,
>
> On Mon, 2026-05-18 at 13:16 +0200, Andre Przywara wrote:
>>>> And anyway, I see a *dual* USB-A socket on the pictures online, in
>>>> addition to the USB-OTG port. So where does the third USB come from? The
>>>> A133 only supports one host USB port plus the one OTG port. So is there
>>>> an USB hub chip on the board?
>>>
>>> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
>>
>> What do you mean with OTG side hub, exactly? Is there a hub on USB0? How
>> does this work, then?
>
> the upstream port of this hub is wired to the USB-C connector, one port has
> CH340E USB-UART on it for the console, the other port goes to the SoC usbphy 0.
> So it would be "peripheral" only, I suppose.
Ah, that's interesting, I was wondering about this, but don't think we
have seen this before.
So yeah, then it's definitely peripheral only. And please state in the
comment that it's connected to the downstream port of a hub, so changing
it to "host" will not work.
Thanks,
Andre
^ permalink raw reply
* Re: [PATCH v4 0/3] arm64: dts/bindings: Add support for BeagleBadge
From: Nishanth Menon @ 2026-05-18 12:49 UTC (permalink / raw)
To: Judith Mendez
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel, Andrew Davis, Bryan Brattlof, Jason Kridner,
Robert Nelson
In-Reply-To: <20260515153541.294698-1-jm@ti.com>
On 10:35-20260515, Judith Mendez wrote:
> Hi,
>
> BeagleBoard.org BeagleBadge[1] is a compact, affordable open source
> hardware [2] single board computer based on the Texas Instruments AM62L3
> SoC designed for IoT and embedded applications. Add base support for
> the same.
>
> SD boot:
> Link: https://gist.github.com/jmenti/8818fa277597de927dd2b42ab1d2552f
in all patches,
Is https://www.beagleboard.org/boards/beaglebadge a better canonical
link?
Robert/Jason: for some reason https://www.beagleboard.org/boards does'nt
list it. Is there a reason?
>
> This patch series adds:
> - Device tree bindings update for am62l3-badge
> - Device tree source for BeagleBadge board
> - Defconfig: drivers for BeagleBadge
>
> Changelog since v3:
> - Fix newline in commit messages
> - Drop vendor URLs
> DTS:
> - Add bootph flags in wakup i2c & PMIC nodes for completeness
> - Drop unneeded header files
>
> v3
> Link: https://lore.kernel.org/all/20260513233447.2713737-1-jm@ti.com/
> V2
> Link: https://lore.kernel.org/all/20260508230341.1891450-1-jm@ti.com/
> V1
> Link: https://lore.kernel.org/all/20260501233148.4180391-1-jm@ti.com/
>
> Patch series depends on:
> Link: https://lore.kernel.org/all/20260513231154.2703292-1-jm@ti.com/
>
> [1] https://www.beagleboard.org/boards/beaglebadge
> [2] https://github.com/beagleboard/BeagleBadge/blob/main/design/BeagleBadge_RevA_V0.7_SCH_251107.pdf
>
> Judith Mendez (3):
> dt-bindings: arm: ti: Add am62l3-beaglebadge
> arm64: dts: ti: Add k3-am62l3-beaglebadge
> arm64: defconfig: Enable drivers for BeagleBadge
>
> .../devicetree/bindings/arm/ti/k3.yaml | 1 +
> arch/arm64/boot/dts/ti/Makefile | 1 +
> .../boot/dts/ti/k3-am62l3-beaglebadge.dts | 700 ++++++++++++++++++
> arch/arm64/configs/defconfig | 5 +
> 4 files changed, 707 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
>
> --
> 2.54.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: yosemite5: Add MP5998 power monitor
From: Andrew Jeffery @ 2026-05-18 12:44 UTC (permalink / raw)
To: Daniel Hsu
Cc: robh, krzk+dt, conor+dt, joel, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, Daniel Hsu
In-Reply-To: <20260331120734.39260-1-Daniel-Hsu@quantatw.com>
Hi Daniel,
On Tue, 2026-03-31 at 20:07 +0800, Daniel Hsu wrote:
> Add an MP5998 power monitor used to monitor the power consumption
> of the Paddle_P12V_HSC rail on the Yosemite5 paddle board.
>
> [v2]
> - Describe the purpose of the power monitor
> - Remove software/driver related description
>
> Signed-off-by: Daniel Hsu <Daniel-Hsu@quantatw.com>
I've applied this to the BMC tree. However, in the future, the
changelog for the series should go underneath '---' below, so it's not
included in the commit message when the patch is applied.
Andrew
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
> index 2486981f3d6b..6287f80d70d9 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
> @@ -422,6 +422,11 @@ power-sensor@45 {
> shunt-resistor = <1000>;
> };
>
> + power-monitor@46 {
> + compatible = "mps,mp5998";
> + reg = <0x46>;
> + };
> +
> power-monitor@47 {
> compatible = "ti,tps25990";
> reg = <0x47>;
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a78000: Describe all reserved memory
From: Marek Vasut @ 2026-05-18 12:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdVcpR96smOd4sdEXHoRp=WTLLzWNN9hO0P0=ZBTe4fKog@mail.gmail.com>
On 5/18/26 9:18 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> + /* TEE TZ DRAM. */
>> + tee@8c400000 {
>> + reg = <0x0 0x8c400000 0x0 0x02000000>;
>> + no-map;
>> + };
>> + };
>
> Shouldn't these reservations be added by the bootloader stack, when
> passing the DTB to Linux?
They should be added by the bootloader stack components, TFA and TEE,
but they do not generate those reservation nodes thus far. TFA I can fix
up for 2.16 (2.15 is in code freeze now), optee-os will need upstreaming
of all the outstanding patches first, and then this can be fixed too.
This is all long term plan though. Short term plan, which also prevents
issues with SDK TFA/TEE, is this reserved memory node.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v2 2/5] arm64/mm: drop vmemmap_pmd helpers and use generic code
From: Will Deacon @ 2026-05-18 12:33 UTC (permalink / raw)
To: Muchun Song
Cc: Catalin Marinas, linux-mm, akpm, Muchun Song, Ryan Roberts,
David Hildenbrand, Kevin Brodsky, Dev Jain, Lorenzo Stoakes,
Anshuman Khandual, Yang Shi, Chaitanya S Prakash,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260404122105.3989557-3-songmuchun@bytedance.com>
On Sat, Apr 04, 2026 at 08:20:55PM +0800, Muchun Song wrote:
> The generic implementations now suffice; remove the arm64 copies.
>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> ---
> arch/arm64/mm/mmu.c | 14 --------------
> 1 file changed, 14 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ec1c6971a561..b87053452641 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1745,20 +1745,6 @@ static void free_empty_tables(unsigned long addr, unsigned long end,
> }
> #endif
>
> -void __meminit vmemmap_set_pmd(pmd_t *pmdp, void *p, int node,
> - unsigned long addr, unsigned long next)
> -{
> - pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
> -}
> -
> -int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node,
> - unsigned long addr, unsigned long next)
> -{
> - vmemmap_verify((pte_t *)pmdp, node, addr, next);
> -
> - return pmd_sect(READ_ONCE(*pmdp));
> -}
I think this is fine:
Acked-by: Will Deacon <will@kernel.org>
but note that, since c25c4aa3f79a ("arm64: mm: Add PTE_DIRTY back to
PAGE_KERNEL* to fix kexec/hibernation"), I think that using PAGE_KERNEL
(like the generic code does in the first patch of this series) means
that this change isn't a no-op -- it means that the huge entries will
now be marked as dirty. That's possibly a bug fix (?)
Will
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iommu: arm,smmu: Document optional interconnects property
From: Krzysztof Kozlowski @ 2026-05-18 12:33 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
In-Reply-To: <20260516-smmu_interconnect_addition-v1-1-f889d933f5c1@oss.qualcomm.com>
On Sat, May 16, 2026 at 06:04:03PM +0530, Bibek Kumar Patro wrote:
> Some SoC implementations require a bandwidth vote on an interconnect
Then this should be disallowed for other devices in "allOf:".
> path before the SMMU register space is accessible. Add the optional
> 'interconnects' property to the binding to allow platform DT nodes
> to describe this path.
>
> The arm-smmu driver uses these properties to vote for bandwidth before
> accessing any SMMU registers and releases the vote on runtime suspend.
>
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 06fb5c8e7547cb7a92823adc2772b94f747376a6..5cbf944f2d3e178b3723d4dbaa19ee0d33446979 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -243,6 +243,15 @@ properties:
> minItems: 1
> maxItems: 3
>
> + interconnects:
> + maxItems: 1
> + description:
> + Optional interconnect path to the SMMU register space. On some SoCs
> + the SMMU registers are only accessible after a bandwidth vote has been
Drivers are irrelevant here, drop. Also first sentence is redundant.
Schema says what is and what is not optional.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Catalin Marinas @ 2026-05-18 12:33 UTC (permalink / raw)
To: Kohei Enju
Cc: Will Deacon, Sami Mujawar, Gavin Shan, Steven Price,
Suzuki K Poulose, linux-arm-kernel, linux-kernel
In-Reply-To: <20260518033157.1865498-1-enju.kohei@fujitsu.com>
On Mon, May 18, 2026 at 12:31:31PM +0900, Kohei Enju wrote:
> With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of
> debug_smp_processor_id(). This debug function complains when certain
> conditions that ensure CPU ID stability are not met, specifically when
> it's called from a preemptible context.
>
> In arm_cca_report_new(), which runs in a preemptible context,
> smp_processor_id() triggers a splat [0] due to this.
>
> However, the CPU ID obtained here is used as the target CPU for
> smp_call_function_single() to designate a specific CPU for subsequent
> operations, not to assert that the current thread will continue to
> execute on the same CPU. Therefore, snapshotting the CPU ID itself is
> correct, and thus there's no actual harm except for the splat.
>
> Use raw_smp_processor_id() instead, to directly retrieve the current CPU
> ID without the debug checks, avoiding the unnecessary warning message
> while preserving the correct functional behavior.
>
> [0]
> BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/134
> caller is debug_smp_processor_id+0x20/0x2c
> CPU: 0 UID: 0 PID: 134 Comm: cca-workload-at Not tainted 7.0.0-rc1-gc74a64d12073 #1 PREEMPT
> Hardware name: linux,dummy-virt (DT)
> Call trace:
> [...]
> check_preemption_disabled+0xf8/0x100
> debug_smp_processor_id+0x20/0x2c
> arm_cca_report_new+0x54/0x230
> tsm_report_read+0x184/0x260
> tsm_report_outblob_read+0x18/0x38
> configfs_bin_read_iter+0xf4/0x1dc
> vfs_read+0x230/0x31c
> [...]
>
> Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
> Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
> ---
> drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> index 0c9ea24a200c..2d450caee3e4 100644
> --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> @@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> * allocate outblob based on the returned value from the 'init'
> * call and that cannot be done in an atomic context.
> */
> - cpu = smp_processor_id();
> + cpu = raw_smp_processor_id();
That's just hiding the warning which might be genuine, irrespective of
what the comment says. Sashiko has some good points:
https://sashiko.dev/#/patchset/20260518033157.1865498-1-enju.kohei@fujitsu.com
Basically what guarantees that the cpu won't go offline? Can we use
migrate_disable() and ignore the smp_call_function_single() altogether?
It looks like a hack anyway.
We should also look at the other unrelated findings in this function
from Sashiko.
--
Catalin
^ 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