* [PATCH v2 02/14] firmware: arm_scmi: Fix transport device teardown lookup
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
SCMI transport devices are deliberately excluded from normal SCMI bus
matching so protocol drivers cannot bind to the internal transport
children. However, scmi_device_destroy() uses the same protocol/name
lookup to find devices that must be unregistered during channel teardown.
Split the match helper so driver matching still skips transport devices,
while explicit child lookup can find them for teardown. Use a shared
transport-device name prefix macro for both matching and name generation.
Since transport-device names are derived from direction and protocol ID,
reject duplicate protocol channel setup before creating or finding a
transport device. This prevents malformed firmware with duplicate
protocol child nodes from reusing an existing transport device and then
destroying it when the duplicate IDR insertion fails.
Fixes: 9593804c44c2 ("firmware: arm_scmi: Exclude transport devices from bus matching")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/bus.c | 22 +++++++++++++++++-----
drivers/firmware/arm_scmi/common.h | 2 ++
drivers/firmware/arm_scmi/driver.c | 5 ++++-
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index f643a1f0e282..d4beefa4234f 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -201,21 +201,33 @@ scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
scmi_protocol_device_unrequest(entry);
}
-static int scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
- const struct scmi_device_id *id_table)
+static bool scmi_device_is_transport(const struct scmi_device *scmi_dev)
+{
+ return !strncmp(scmi_dev->name, SCMI_TRANSPORT_DEVNAME_PREFIX,
+ strlen(SCMI_TRANSPORT_DEVNAME_PREFIX));
+}
+
+static int __scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
+ const struct scmi_device_id *id_table,
+ bool skip_transport)
{
if (!id_table || !id_table->name)
return 0;
- /* Always skip transport devices from matching */
for (; id_table->protocol_id && id_table->name; id_table++)
if (id_table->protocol_id == scmi_dev->protocol_id &&
- strncmp(scmi_dev->name, "__scmi_transport_device", 23) &&
+ !(skip_transport && scmi_device_is_transport(scmi_dev)) &&
!strcmp(id_table->name, scmi_dev->name))
return 1;
return 0;
}
+static int scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
+ const struct scmi_device_id *id_table)
+{
+ return __scmi_dev_match_by_id_table(scmi_dev, id_table, true);
+}
+
static int scmi_dev_match_id(struct scmi_device *scmi_dev,
const struct scmi_driver *scmi_drv)
{
@@ -235,7 +247,7 @@ static int scmi_match_by_id_table(struct device *dev, const void *data)
struct scmi_device *scmi_dev = to_scmi_dev(dev);
const struct scmi_device_id *id_table = data;
- return scmi_dev_match_by_id_table(scmi_dev, id_table);
+ return __scmi_dev_match_by_id_table(scmi_dev, id_table, false);
}
static struct scmi_device *scmi_child_dev_find(struct device *parent,
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index b9723c105fc1..fe8c22cfb9f7 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -34,6 +34,8 @@
#define SCMI_SHMEM_MAX_PAYLOAD_SIZE 104
+#define SCMI_TRANSPORT_DEVNAME_PREFIX "__scmi_transport_device"
+
enum scmi_error_codes {
SCMI_SUCCESS = 0, /* Success */
SCMI_ERR_SUPPORT = -1, /* Not supported */
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index b9245238e293..b9ba566fc759 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2751,6 +2751,9 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
idx = tx ? 0 : 1;
idr = tx ? &info->tx_idr : &info->rx_idr;
+ if (idr_find(idr, prot_id))
+ return -EEXIST;
+
if (!info->desc->ops->chan_available(of_node, idx)) {
cinfo = idr_find(idr, SCMI_PROTOCOL_BASE);
if (unlikely(!cinfo)) /* Possible only if platform has no Rx */
@@ -2768,7 +2771,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
cinfo->no_completion_irq = info->desc->no_completion_irq;
/* Create a unique name for this transport device */
- snprintf(name, 32, "__scmi_transport_device_%s_%02X",
+ snprintf(name, sizeof(name), SCMI_TRANSPORT_DEVNAME_PREFIX "_%s_%02X",
idx ? "rx" : "tx", prot_id);
/* Create a uniquely named, dedicated transport device for this chan */
tdev = scmi_device_create(of_node, info->dev, prot_id, name);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 00/14] firmware: arm_scmi: Fix SCMI core cleanup paths
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
This series fixes a set of SCMI core and mailbox transport lifetime issues
found around device creation, channel setup failure, notification teardown
and malformed firmware descriptions.
Most of these issues were found by Sashiko[1][2] while reviewing the ACPI SCMI
PCC work[3]. They are posted separately because the problems are independent
SCMI core and mailbox transport cleanup bugs, and do not depend on the ACPI
PCC series.
Here is the attempt to fix them, some of them can be dropped if it is too
theoretical. I have addressed all the issues that made sense to me at the
time of reading the report.
The fixes tighten ownership and teardown rules for generated SCMI devices,
transport devices and transport channels. They make internal transport
devices reachable by explicit teardown without exposing them to normal SCMI
driver binding, ensure partially initialized channels are unwound on setup
failures, and avoid IDR/device lifetime races during probe failure and device
unbind.
The series also fixes notifier and notification teardown ordering. Requested
device notifiers are unregistered before protocol IDRs are destroyed, RCU is
used around requested-device protocol lookups, and transport callbacks are
stopped before notification state is released.
The mailbox transport fixes cover both setup failure unwinding and an early
interrupt window: mailbox callbacks can run as soon as mbox_request_channel()
binds the client and starts the controller, so the SCMI mailbox transport now
publishes its cinfo before requesting channels.
Fixes tags need to be checked again or even dropped if it is not a stable
material. Just some placeholders that I thought are appropriated are in place.
Summary:
- Fix OF node reference ownership for generated SCMI devices.
- Allow explicit teardown lookup of internal transport devices.
- Clean up TX/RX channels when SCMI channel setup fails midway.
- Fix SCMI device lifetime handling around child lookup and bus ID reuse.
- Free transport resources when IDR insertion fails after channel setup.
- Unregister requested-device notifier before active protocol IDR teardown.
- Unwind mailbox channels on TX receiver and P2A receiver setup failures.
- Protect requested-device protocol lookup with RCU.
- Avoid modifying an IDR while iterating it during channel cleanup.
- Clear the SystemPower singleton flag on SCMI device creation failure.
- Reject out-of-range DT protocol IDs instead of allowing u8 truncation.
- Stop transport callbacks before releasing notification state.
- Publish mailbox cinfo before requesting mailbox channels.
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
[1] https://sashiko.dev/#/patchset/20260525-acpi_scmi_pcc-v2-0-4f38938d08d8@arm.com
[2] https://sashiko.dev/#/patchset/20260630-scmi_core_fixes-v1-0-f932c1e51992@kernel.org
[3] https://patch.msgid.link/20260525-acpi_scmi_pcc-v2-0-4f38938d08d8@arm.com
---
Changes in v2:
(Mostly addressing the additional issues found by Sashiko)
- Added fixes for IDR mutation during channel cleanup.
- Added SystemPower singleton flag unwind on device creation failure.
- Added validation to skip out-of-range DT protocol IDs.
- Moved notification teardown after transport channel cleanup.
- Published mailbox cinfo before mbox_request_channel() can enable callbacks.
- Link to v1: https://patch.msgid.link/20260630-scmi_core_fixes-v1-0-f932c1e51992@kernel.org
---
Sudeep Holla (14):
firmware: arm_scmi: Fix OF node reference handling
firmware: arm_scmi: Fix transport device teardown lookup
firmware: arm_scmi: Clean up channels on setup failure
firmware: arm_scmi: Fix SCMI device destroy lifetimes
firmware: arm_scmi: Free transport channel on IDR failure
firmware: arm_scmi: Unregister device notifier before IDR teardown
firmware: arm_scmi: Unwind TX receiver mailbox setup failure
firmware: arm_scmi: Unwind P2A receiver mailbox setup failure
firmware: arm_scmi: Protect device request lookup with RCU
firmware: arm_scmi: Avoid IDR updates while cleaning channels
firmware: arm_scmi: Clear SystemPower flag on create failure
firmware: arm_scmi: Reject out of range DT protocol IDs
firmware: arm_scmi: Stop channels before notification teardown
firmware: arm_scmi: Publish mailbox cinfo before channel request
drivers/firmware/arm_scmi/bus.c | 72 ++++++++++++++++----------
drivers/firmware/arm_scmi/common.h | 2 +
drivers/firmware/arm_scmi/driver.c | 44 +++++++++-------
drivers/firmware/arm_scmi/transports/mailbox.c | 26 +++++++---
4 files changed, 90 insertions(+), 54 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260629-scmi_core_fixes-da3cd753b4ea
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 03/14] firmware: arm_scmi: Clean up channels on setup failure
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
scmi_channels_setup() can fail after the common BASE channel or earlier
protocol channels have already been registered in the TX/RX IDRs.
Route this failure through the existing channel cleanup label so the
transport channels, transport devices and IDR state created before the
failure are released before the probe error path frees the SCMI instance
ID.
Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index b9ba566fc759..861087b2920e 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -3262,7 +3262,7 @@ static int scmi_probe(struct platform_device *pdev)
ret = scmi_channels_setup(info);
if (ret) {
err_str = "failed to setup channels\n";
- goto clear_ida;
+ goto clear_txrx_setup;
}
ret = bus_register_notifier(&scmi_bus_type, &info->bus_nb);
@@ -3377,7 +3377,6 @@ static int scmi_probe(struct platform_device *pdev)
bus_unregister_notifier(&scmi_bus_type, &info->bus_nb);
clear_txrx_setup:
scmi_cleanup_txrx_channels(info);
-clear_ida:
ida_free(&scmi_id, info->id);
out_err:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 04/14] firmware: arm_scmi: Fix SCMI device destroy lifetimes
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
scmi_child_dev_find() drops the reference returned by
device_find_child() before returning the scmi_device pointer. A
concurrent unregister can then release the device while the destroy path
is still using the returned pointer.
Make the lookup helper return the device_find_child() reference and keep
it until scmi_device_destroy() has finished unregistering the child.
Also split device_unregister() in __scmi_device_destroy() so the SCMI bus
ID is not made reusable until after device_del() has removed the old
scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the
same ID while the old device is still registered.
Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback")
Fixes: 9ca67840c0dd ("firmware: arm_scmi: Balance device refcount when destroying devices")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/bus.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index d4beefa4234f..e1deb1b3011d 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -250,8 +250,9 @@ static int scmi_match_by_id_table(struct device *dev, const void *data)
return __scmi_dev_match_by_id_table(scmi_dev, id_table, false);
}
-static struct scmi_device *scmi_child_dev_find(struct device *parent,
- int prot_id, const char *name)
+/* Returns a device_find_child() reference which must be dropped by caller. */
+static struct scmi_device *
+scmi_child_dev_find_get(struct device *parent, int prot_id, const char *name)
{
struct scmi_device_id id_table[2] = { 0 };
struct device *dev;
@@ -263,9 +264,6 @@ static struct scmi_device *scmi_child_dev_find(struct device *parent,
if (!dev)
return NULL;
- /* Drop the refcnt bumped implicitly by device_find_child */
- put_device(dev);
-
return to_scmi_dev(dev);
}
@@ -422,8 +420,9 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
atomic_set(&scmi_syspower_registered, 0);
+ device_del(&scmi_dev->dev);
ida_free(&scmi_bus_id, scmi_dev->id);
- device_unregister(&scmi_dev->dev);
+ put_device(&scmi_dev->dev);
}
static struct scmi_device *
@@ -440,9 +439,11 @@ __scmi_device_create(struct device_node *np, struct device *parent,
* each DT defined protocol at probe time, and the concurrent
* registration of SCMI drivers.
*/
- scmi_dev = scmi_child_dev_find(parent, protocol, name);
- if (scmi_dev)
+ scmi_dev = scmi_child_dev_find_get(parent, protocol, name);
+ if (scmi_dev) {
+ put_device(&scmi_dev->dev);
return scmi_dev;
+ }
/*
* Ignore any possible subsequent failures while creating the device
@@ -492,8 +493,8 @@ __scmi_device_create(struct device_node *np, struct device *parent,
return scmi_dev;
put_dev:
+ ida_free(&scmi_bus_id, scmi_dev->id);
put_device(&scmi_dev->dev);
- ida_free(&scmi_bus_id, id);
return NULL;
}
@@ -574,9 +575,11 @@ void scmi_device_destroy(struct device *parent, int protocol, const char *name)
{
struct scmi_device *scmi_dev;
- scmi_dev = scmi_child_dev_find(parent, protocol, name);
- if (scmi_dev)
+ scmi_dev = scmi_child_dev_find_get(parent, protocol, name);
+ if (scmi_dev) {
__scmi_device_destroy(scmi_dev);
+ put_device(&scmi_dev->dev);
+ }
}
EXPORT_SYMBOL_GPL(scmi_device_destroy);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 06/14] firmware: arm_scmi: Unregister device notifier before IDR teardown
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
The requested-devices notifier looks up protocol fwnodes from the
active_protocols IDR. During remove, unregister the notifier before
releasing and destroying active_protocols so no notifier callback can race
with the IDR teardown.
Keep the bus notifier registered until after the protocol state is torn
down, matching the existing remove ordering for SCMI bus users.
Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 4b369b003003..6df0fe055d64 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -3402,6 +3402,9 @@ static void scmi_remove(struct platform_device *pdev)
scmi_notification_exit(&info->handle);
+ blocking_notifier_chain_unregister(&scmi_requested_devices_nh,
+ &info->dev_req_nb);
+
mutex_lock(&info->protocols_mtx);
idr_destroy(&info->protocols);
mutex_unlock(&info->protocols_mtx);
@@ -3410,8 +3413,6 @@ static void scmi_remove(struct platform_device *pdev)
of_node_put(child);
idr_destroy(&info->active_protocols);
- blocking_notifier_chain_unregister(&scmi_requested_devices_nh,
- &info->dev_req_nb);
bus_unregister_notifier(&scmi_bus_type, &info->bus_nb);
/* Safe to free channels since no more users */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 05/14] firmware: arm_scmi: Free transport channel on IDR failure
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
If transport channel setup succeeds but the following IDR insertion fails,
the error path destroys the transport device and frees the channel info
without invoking the transport cleanup callback.
Call chan_free() before destroying the device so transport specific
resources such as IRQs, mailbox channels and mapped shared memory are
released consistently with the normal teardown path.
Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 861087b2920e..4b369b003003 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2808,6 +2808,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
"unable to allocate SCMI idr slot err %d\n", ret);
/* Destroy channel and device only if created by this call. */
if (tdev) {
+ info->desc->ops->chan_free(prot_id, cinfo, idr);
scmi_device_destroy(info->dev, prot_id, name);
devm_kfree(info->dev, cinfo);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 07/14] firmware: arm_scmi: Unwind TX receiver mailbox setup failure
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
mailbox_chan_setup() can request an additional unidirectional TX
receiver channel after successfully acquiring the primary channel. If
that second request fails, the function returns immediately and leaves
the primary channel allocated.
Unwind the primary mailbox channel before returning the error so probe
deferral or other setup failures do not leave the channel busy for later
probe attempts.
Fixes: 9f68ff79ec2c ("firmware: arm_scmi: Add support for unidirectional mailbox channels")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/transports/mailbox.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/transports/mailbox.c b/drivers/firmware/arm_scmi/transports/mailbox.c
index ae0f67e6cc45..44d45ce838e5 100644
--- a/drivers/firmware/arm_scmi/transports/mailbox.c
+++ b/drivers/firmware/arm_scmi/transports/mailbox.c
@@ -225,9 +225,10 @@ static int mailbox_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
smbox->chan_receiver = mbox_request_channel(cl, a2p_rx_chan);
if (IS_ERR(smbox->chan_receiver)) {
ret = PTR_ERR(smbox->chan_receiver);
+ smbox->chan_receiver = NULL;
if (ret != -EPROBE_DEFER)
dev_err(cdev, "failed to request SCMI Tx Receiver mailbox\n");
- return ret;
+ goto err_free_chan;
}
}
@@ -246,6 +247,10 @@ static int mailbox_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
mutex_init(&smbox->chan_lock);
return 0;
+
+err_free_chan:
+ mbox_free_channel(smbox->chan);
+ return ret;
}
static int mailbox_chan_free(int id, void *p, void *data)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 08/14] firmware: arm_scmi: Unwind P2A receiver mailbox setup failure
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
mailbox_chan_setup() can request an additional P2A receiver channel after
successfully acquiring the primary P2A channel. If that later request
fails, the function returns immediately and leaves the primary channel
allocated.
Unwind the primary mailbox channel before returning the error so probe
deferral or other setup failures do not leave the channel busy for later
probe attempts.
Fixes: fa8b28ba22d9 ("firmware: arm_scmi: Add support for platform to agent channel completion")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/transports/mailbox.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/transports/mailbox.c b/drivers/firmware/arm_scmi/transports/mailbox.c
index 44d45ce838e5..07a08ea5d9de 100644
--- a/drivers/firmware/arm_scmi/transports/mailbox.c
+++ b/drivers/firmware/arm_scmi/transports/mailbox.c
@@ -236,9 +236,10 @@ static int mailbox_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
smbox->chan_platform_receiver = mbox_request_channel(cl, p2a_rx_chan);
if (IS_ERR(smbox->chan_platform_receiver)) {
ret = PTR_ERR(smbox->chan_platform_receiver);
+ smbox->chan_platform_receiver = NULL;
if (ret != -EPROBE_DEFER)
dev_err(cdev, "failed to request SCMI P2A Receiver mailbox\n");
- return ret;
+ goto err_free_chan;
}
}
@@ -248,6 +249,8 @@ static int mailbox_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
return 0;
+err_free_chan_receiver:
+ mbox_free_channel(smbox->chan_receiver);
err_free_chan:
mbox_free_channel(smbox->chan);
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 10/14] firmware: arm_scmi: Avoid IDR updates while cleaning channels
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
scmi_cleanup_channels() walks the TX/RX channel IDRs with
idr_for_each() to free transport resources and destroy the dedicated
transport devices before calling idr_destroy().
The destroy callback removed each entry from the same IDR being walked.
That is not needed for this cleanup path, and it is unsafe because
idr_for_each() has not advanced its radix-tree iterator while the
callback is running. Removing the current entry from the callback can
invalidate the iterator state. The callback also cannot be protected by
rcu_read_lock(), because scmi_device_destroy() may sleep.
Leave IDR teardown to the following idr_destroy() call and keep the
callback limited to device destruction.
Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index a575e661f1e2..ae4b7128276b 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2886,7 +2886,7 @@ static int scmi_channels_setup(struct scmi_info *info)
return 0;
}
-static int scmi_chan_destroy(int id, void *p, void *idr)
+static int scmi_chan_destroy(int id, void *p, void *data)
{
struct scmi_chan_info *cinfo = p;
@@ -2898,8 +2898,6 @@ static int scmi_chan_destroy(int id, void *p, void *idr)
cinfo->dev = NULL;
}
- idr_remove(idr, id);
-
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 09/14] firmware: arm_scmi: Protect device request lookup with RCU
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
The SCMI device request notifier looks up protocol OF nodes from the
active_protocols IDR. The IDR lookup can run concurrently with protocol
activation while probe is still registering protocols and creating their
SCMI devices.
Wrap the lookup in an RCU read-side critical section as required by the
IDR API for lockless readers.
Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 6df0fe055d64..a575e661f1e2 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -33,6 +33,7 @@
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/processor.h>
+#include <linux/rcupdate.h>
#include <linux/refcount.h>
#include <linux/slab.h>
#include <linux/xarray.h>
@@ -2957,7 +2958,9 @@ static int scmi_device_request_notifier(struct notifier_block *nb,
struct scmi_device_id *id_table = data;
struct scmi_info *info = req_nb_to_scmi_info(nb);
+ rcu_read_lock();
np = idr_find(&info->active_protocols, id_table->protocol_id);
+ rcu_read_unlock();
if (!np)
return NOTIFY_DONE;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 11/14] firmware: arm_scmi: Clear SystemPower flag on create failure
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
__scmi_device_create() reserves the singleton SystemPower protocol
device by setting scmi_syspower_registered before allocating and
registering the SCMI device.
If any later step fails, the function returns NULL but leaves the flag
set. A subsequent retry, for example after probe deferral, then observes
the stale reservation and rejects creation of the SystemPower protocol
device permanently.
Route all failures after the successful reservation through a common
unwind path which clears scmi_syspower_registered again. Keep the
duplicate-device rejection path unchanged because that path did not acquire
the reservation.
Fixes: 2c3e674465e7 ("firmware: arm_scmi: Refactor device create/destroy helpers")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/bus.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index e1deb1b3011d..cdfcd8e96e93 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -431,6 +431,7 @@ __scmi_device_create(struct device_node *np, struct device *parent,
{
int id, retval;
struct scmi_device *scmi_dev;
+ bool syspower = (protocol == SCMI_PROTOCOL_SYSTEM);
/*
* If the same protocol/name device already exist under the same parent
@@ -446,14 +447,12 @@ __scmi_device_create(struct device_node *np, struct device *parent,
}
/*
- * Ignore any possible subsequent failures while creating the device
- * since we are doomed anyway at that point; not using a mutex which
- * spans across this whole function to keep things simple and to avoid
- * to serialize all the __scmi_device_create calls across possibly
- * different SCMI server instances (parent)
+ * Reserve the singleton SystemPower protocol device before
+ * allocation and registration. This keeps creation simple without
+ * a mutex spanning the whole function; error paths after the
+ * reservation must drop it again.
*/
- if (protocol == SCMI_PROTOCOL_SYSTEM &&
- atomic_cmpxchg(&scmi_syspower_registered, 0, 1)) {
+ if (syspower && atomic_cmpxchg(&scmi_syspower_registered, 0, 1)) {
dev_warn(parent,
"SCMI SystemPower protocol device must be unique !\n");
return NULL;
@@ -461,19 +460,19 @@ __scmi_device_create(struct device_node *np, struct device *parent,
scmi_dev = kzalloc_obj(*scmi_dev);
if (!scmi_dev)
- return NULL;
+ goto clear_syspower;
scmi_dev->name = kstrdup_const(name ?: "unknown", GFP_KERNEL);
if (!scmi_dev->name) {
kfree(scmi_dev);
- return NULL;
+ goto clear_syspower;
}
id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
if (id < 0) {
kfree_const(scmi_dev->name);
kfree(scmi_dev);
- return NULL;
+ goto clear_syspower;
}
scmi_dev->id = id;
@@ -495,6 +494,9 @@ __scmi_device_create(struct device_node *np, struct device *parent,
put_dev:
ida_free(&scmi_bus_id, scmi_dev->id);
put_device(&scmi_dev->dev);
+clear_syspower:
+ if (syspower)
+ atomic_set(&scmi_syspower_registered, 0);
return NULL;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 00/42] drm/mediatek: The Huge Restructuring and MT8196 support
From: AngeloGioacchino Del Regno @ 2026-07-01 12:20 UTC (permalink / raw)
To: chunkuang.hu
Cc: p.zabel, airlied, simona, maarten.lankhorst, mripard, tzimmermann,
robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
dri-devel, linux-mediatek, devicetree, linux-kernel,
linux-arm-kernel, justin.yeh, jason-jh.lin, kernel
Okay, yes, this is very big. :-)
This series "only" does two things:
1. Restructures mediatek-drm to optimize components discovery,
pipeline building, changes components relationship, and to
make use new-style trigger-sources for MuteX, other than
paving the way for *easily* adding support for up to 31
concurrent display outputs (of which, 6-8 are realistic now
with newer SoCs); and
2. Adds support for the new DirectLink architecture and for most
of the new Display Controller components found in newer gen
SoCs, like MT8196.
Note that, mixed in all this, there are some changes to the mediatek
MMSYS driver: those *cannot* be performed separately, and *must* land
in the same moment as the other changes, as otherwise it's all going
to break.
That was unavoidable, unless adding another ~10 (big) commits to keep
support for old code while introducing the new (not devicetree, just
code, mind you!) which is, at this point, completely unnecessary and
just big noise for no reason.
The two soc/mediatek commits already have my Acked-by tag for them to
be picked by a drm maintainer instead.
Important summary done, let's go deeper!
(from mtk-mmsys new-style series, important context)
As of now, all of the components in MediaTek DRM, hence also in the
MMSYS driver, are thrown in a catch-all enumeration that does not
make any distinction between Type-Instance relationship, and it is
like so (mock-up names ahead):
DISPLAY_DITHER0
DISPLAY_DITHER1
DISPLAY_DSI0
DISPLAY_DSI1
... and so on.
Since the number of components is now becoming uncontrollably large,
the catch-all enumeration poses a big issue as the mediatek-drm driver
is allocating a huge array that will be only half full (optimistically,
because usually it's way less than half full) and with repeated ops
assignment for each and every instance of the very same Sub-IP,
effectively treating every instance of a Sub-IP like it is completely
different from one another (for example, like DSI0 and DSI1 are as
different as DITHER0 and DSI1).
This has to change. It had to change months ago, but now it has become
not only a maintenance burden, but also a... (sorry) big mess.
And well, that... especially looking forward to add support for newer
SoCs, using even more components in one pipeline, and using different
and newer components (of new types...), making the catch-all enum to
grow of another ~20 entries or more.
(end of context paste)
This is the reason why the mediatek-drm driver now structures the HW
components in a different way, and specifically, it now makes a clear
distinction between HARDWARE TYPE and HARDWARE INSTANCE ID.
With this distinction is done, it also made sense to change the highly
unoptimized array search with a hashtable, making the entire components
discovery process faster (with or without MT8196 support), while using
less memory (compared to if this driver had MT8196 support without the
restructured code).
Moreover, the mediatek-drm driver now supports dynamic selection of the
DMA device, the VBLANK component and of the CONFIG component, necessary
for Multi-Controller Display Path (with DirectLink) architecture of new
SoCs (like MT8196), and also makes it possible for slightly older ones
to use multi-controller paths (though very restrictive due to the actual
hardware support).
Moving on to the MT8196 specific support...
This adds knowledge to mediatek-drm and hence introduces support for
the new concept of "Layer Stages", seen in MT6991/93, MT8196/8894 and
other new SoCs, where each (one) full layer is now composed of multiple
different hardware IPs and where, depending on the usecase (which is
BOARD specific!!!), can be set to have less, or more, capabilities in
terms of number of Blending stages, number of DMA stages, etc, so that
one board may choose to have up to 6-8 display outputs featuring lower
resolution displays, or 2-3 outputs supporting high resolution with high
framerates (like 4k120, 8k60 etc).
This also restructures the MediaTek DPI driver to be split in a common
library and HW version specific drivers, and on the base of this, adds
support for the new MediaTek Display Video Output (DVO) hardware, being
a revised and extended version of the previous DPI one.
Moreover, adds support for the Extended DMA (exDMA), Blender and Output
Processor engines, providing single stages of layers and forming one
layer when chained together.
More new-gen components include the 2D Sharpness Processor (TDSHP) and
the Display Image Resizer (effectively, a Scaler engine).
This also adds support for the Asynchronous DirectLink Controller, or
"DL_ASYNC", responsible for internally connecting different display
controllers to finally form one (or multiple) display path(s), which
may include a relatively infinite (real, and full) display controller
jumps or even intertwining (where jumps are fully supported in this
version of the driver, but intertwining is only partially supported).
In the case of paths using multiple display controllers, this is now
automatically calculating the order of those, important not only for
power management, but also for actually setting them up.
There's more to say, but this cover letter is already way too long now
so, well, if you want to know more about this, please the description
in the relevant commit from this series and feel free to ask for any
clarification.
All of this was manually tested on multiple MediaTek boards, both the
reference ones and partner boards, and that includes:
Acer Chromebook Elm (MT8173)
Acer Chromebook Corsola Steelix (MT8186)
Acer Chromebook Asurada (MT8192)
Acer Chromebook Cherry Tomato (MT8195)
Acer Chromebook Rauru Hylia (MT8196)
MediaTek Genio 510 EVK (MT8370)
MediaTek Genio 700 EVK (MT8390)
MediaTek Genio 1200 EVK (MT8395)
Radxa NIO-12L (MT8395)
Note: with this series, MT8196 support reaches a 95% done state for
DSI or eDP outputs, but needs some more code to work; the test that
was performed on the Hylia Chromebook had the rest of the required
code in place: said code is not perfectly clean yet and was not sent
for this exact reason. Cleanups to the remaining MT8196 code will
not change anything of what is introduced with this patch series.
AngeloGioacchino Del Regno (39):
drm/mediatek: Move mtk_ddp_comp_type enumeration to mtk-mmsys.h
drm/mediatek: Rename all display component type to have DISP_ prefix
drm/mediatek: Use hashtable for components discovery and registration
drm/mediatek: ddp_comp: Move internal component register in function
drm/mediatek: De-duplicate internal component checks
drm/mediatek: Introduce and use path/comp definition structures
drm/mediatek: Create new mtk_drm_legacy and move deprecated code
drm/mediatek: Add support for MuteX trigger-sources parsing
drm/mediatek: ovl_adaptor: Add special MERGE component check
drm/mediatek: mtk_hdmi_v2: Don't warn on RPM active during detach
drm/mediatek: Add support for hardware multi-stage layers
drm/mediatek: mtk_crtc: Complete documentation for struct mtk_crtc
drm/mediatek: mtk_crtc: Minimize spinlocked time in cmdq callback
drm/mediatek: mtk_crtc: Dynamically find vblank/cfg component indices
soc: mediatek: mtk-mmsys: Migrate to new Multimedia DDP HW indexing
drm/mediatek: Fully migrate to new Display Controller HW indexing
drm/mediatek: mtk_dpi: Pass parameters with new mtk_dpi_sync structure
drm/mediatek: mtk_dpi: Fully separate HW setup from common code
drm/mediatek: Create new mtk_dpi_common lib and move mtk_dpi code
dt-bindings: display: mediatek: Introduce Digital Video Output HW
drm/mediatek: Add support for MediaTek Digital Video Output (DVO)
drm/mediatek: Pass mtk_ddp_comp in clk and config callbacks
dt-bindings: display: mediatek: Introduce MT8196 Layer Blender
drm/mediatek: Add support for Display Layer Blender component
dt-bindings: display: mediatek: Introduce MT8196 extended DMA Engine
drm/mediatek: Add support for Display Controller exDMA component
dt-bindings: display: mediatek: Introduce MT8196 Output Processor
drm/mediatek: Add support for Display Output Processor component
drm/mediatek: mtk_crtc: Dynamically find suitable CRTC DMA device
drm/mediatek: Prepare path builder for multi-controller architecture
drm/mediatek: Enable bring-up of multi-controller CRTC paths
drm/mediatek: Introduce MediaTek Asynchronous DirectLink Controller
drm/mediatek: Support registering disp controller device subnodes
soc: mediatek: mtk-mmsys: Populate multimedia subsystem subdevices
dt-bindings: display: mediatek: Introduce MT8196 2D Sharpness
Processor
drm/mediatek: Add Two-Dimension Sharpness Processor (TDSHP) driver
dt-bindings: display: mediatek: Introduce MT8196 Image Resizer
drm/mediatek: Add support for Display Image Resizer (Scaler)
drm/mediatek: mtk_drm_drv: Fail init only if all paths are invalid
Nancy Lin (1):
drm/mediatek: Export OVL formats definitions and format conversion API
Paul-pl Chen (2):
drm/mediatek: Rename OVL format naming
drm/mediatek: Export OVL Blend function
.../mediatek/mediatek,mt8196-blender.yaml | 97 ++
.../display/mediatek/mediatek,mt8196-dvo.yaml | 142 +++
.../mediatek/mediatek,mt8196-exdma.yaml | 104 ++
.../mediatek/mediatek,mt8196-outproc.yaml | 107 ++
.../display/mediatek/mediatek,mt8196-rsz.yaml | 97 ++
.../mediatek/mediatek,mt8196-tdshp.yaml | 98 ++
drivers/gpu/drm/mediatek/Makefile | 8 +
drivers/gpu/drm/mediatek/mtk_crtc.c | 978 ++++++++++----
drivers/gpu/drm/mediatek/mtk_crtc.h | 4 +-
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 457 ++++---
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 145 ++-
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 12 +-
drivers/gpu/drm/mediatek/mtk_disp_blender.c | 318 +++++
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 12 +-
drivers/gpu/drm/mediatek/mtk_disp_color.c | 12 +-
.../gpu/drm/mediatek/mtk_disp_directlink.c | 434 +++++++
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 158 ++-
drivers/gpu/drm/mediatek/mtk_disp_dsc.c | 8 +-
drivers/gpu/drm/mediatek/mtk_disp_exdma.c | 344 +++++
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 12 +-
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 18 +-
drivers/gpu/drm/mediatek/mtk_disp_outproc.c | 247 ++++
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 274 ++--
drivers/gpu/drm/mediatek/mtk_disp_ovl.h | 27 +
.../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 182 ++-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 21 +-
drivers/gpu/drm/mediatek/mtk_disp_tdshp.c | 167 +++
drivers/gpu/drm/mediatek/mtk_disp_wdma.c | 14 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 760 ++---------
drivers/gpu/drm/mediatek/mtk_dpi_common.c | 473 +++++++
drivers/gpu/drm/mediatek/mtk_dpi_common.h | 299 +++++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1121 ++++++++++-------
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 34 +-
drivers/gpu/drm/mediatek/mtk_drm_legacy.c | 879 +++++++++++++
drivers/gpu/drm/mediatek/mtk_drm_legacy.h | 37 +
drivers/gpu/drm/mediatek/mtk_dvo.c | 682 ++++++++++
drivers/gpu/drm/mediatek/mtk_dvo_regs.h | 192 +++
drivers/gpu/drm/mediatek/mtk_ethdr.c | 10 +-
drivers/gpu/drm/mediatek/mtk_ethdr.h | 4 +-
drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 2 -
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 8 +-
drivers/gpu/drm/mediatek/mtk_padding.c | 8 +-
drivers/soc/mediatek/mtk-mmsys.c | 111 +-
drivers/soc/mediatek/mtk-mmsys.h | 14 +-
include/linux/soc/mediatek/mtk-mmsys.h | 56 +-
45 files changed, 7279 insertions(+), 1908 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-blender.yaml
create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml
create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-exdma.yaml
create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-outproc.yaml
create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-rsz.yaml
create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-tdshp.yaml
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_blender.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_directlink.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_exdma.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_outproc.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_tdshp.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi_common.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi_common.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_legacy.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_legacy.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_dvo.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dvo_regs.h
--
2.54.0
^ permalink raw reply
* [PATCH v2 12/14] firmware: arm_scmi: Reject out of range DT protocol IDs
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
SCMI protocol IDs carried in message headers are limited by
MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs
outside that range, but only logged an error and then kept processing
the invalid value.
That lets a malformed 32-bit DT reg value reach helpers which take a u8
protocol ID, where it can be truncated and/or treated as a different
protocol.
For channel setup, two different out-of-range values can also be used as
distinct IDR keys while aliasing the generated SCMI protocol identity.
Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID
field before setting up channels or creating protocol devices.
Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index ae4b7128276b..f515b192c1bd 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2874,9 +2874,11 @@ static int scmi_channels_setup(struct scmi_info *info)
if (of_property_read_u32(child, "reg", &prot_id))
continue;
- if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
+ if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id)) {
dev_err(info->dev,
"Out of range protocol %d\n", prot_id);
+ continue;
+ }
ret = scmi_txrx_setup(info, child, prot_id);
if (ret)
@@ -3341,8 +3343,10 @@ static int scmi_probe(struct platform_device *pdev)
if (of_property_read_u32(child, "reg", &prot_id))
continue;
- if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
+ if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id)) {
dev_err(dev, "Out of range protocol %d\n", prot_id);
+ continue;
+ }
if (!scmi_is_protocol_implemented(handle, prot_id)) {
dev_err(dev, "SCMI protocol %d not implemented\n",
--
2.43.0
^ permalink raw reply related
* [PATCH v2 14/14] firmware: arm_scmi: Publish mailbox cinfo before channel request
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
mailbox_chan_setup() initializes smbox->cinfo only after all mailbox
channels have been requested successfully. That is too late because
mbox_request_channel() binds the client before invoking the controller
startup callback, and startup can enable interrupt delivery.
If a pending or spurious mailbox interrupt fires during that window,
mbox_chan_received_data() can call the SCMI mailbox rx_callback() before
smbox->cinfo is set. The callback dereferences smbox->cinfo on both the
spurious IRQ path and the normal RX path, so this can crash before
channel setup has completed.
Publish cinfo->transport_info and smbox->cinfo, and initialize the
chan_lock, before requesting any mailbox channel. Clear the early
published pointers again on setup failure so later cleanup does not see
a half-initialized transport.
Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/transports/mailbox.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/arm_scmi/transports/mailbox.c b/drivers/firmware/arm_scmi/transports/mailbox.c
index 07a08ea5d9de..f1bee48ef7dd 100644
--- a/drivers/firmware/arm_scmi/transports/mailbox.c
+++ b/drivers/firmware/arm_scmi/transports/mailbox.c
@@ -211,13 +211,18 @@ static int mailbox_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
cl->tx_block = false;
cl->knows_txdone = tx;
+ cinfo->transport_info = smbox;
+ smbox->cinfo = cinfo;
+ mutex_init(&smbox->chan_lock);
+
smbox->chan = mbox_request_channel(cl, tx ? 0 : p2a_chan);
if (IS_ERR(smbox->chan)) {
ret = PTR_ERR(smbox->chan);
+ smbox->chan = NULL;
if (ret != -EPROBE_DEFER)
dev_err(cdev,
"failed to request SCMI %s mailbox\n", desc);
- return ret;
+ goto err_clear_cinfo;
}
/* Additional unidirectional channel for TX if needed */
@@ -243,16 +248,15 @@ static int mailbox_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
}
}
- cinfo->transport_info = smbox;
- smbox->cinfo = cinfo;
- mutex_init(&smbox->chan_lock);
-
return 0;
err_free_chan_receiver:
mbox_free_channel(smbox->chan_receiver);
err_free_chan:
mbox_free_channel(smbox->chan);
+err_clear_cinfo:
+ cinfo->transport_info = NULL;
+ smbox->cinfo = NULL;
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 13/14] firmware: arm_scmi: Stop channels before notification teardown
From: Sudeep Holla @ 2026-07-01 16:52 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel; +Cc: Cristian Marussi
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>
scmi_notification_exit() clears and releases the notification instance,
but transport callbacks can still deliver incoming notifications until
the TX/RX channels are freed.
During remove, an RX interrupt in that window can enter scmi_notify()
while the notification instance is being torn down and then dereference
freed notification state. The same ordering exists on the probe error
path after notification initialization.
Unregister the requested device notifier first, then stop transport
callbacks by cleaning up the TX/RX channels before releasing the
notification core. This keeps the notification data alive until no
transport callback can queue or process a new event.
Fixes: 1e7cbfaa66d3 ("firmware: arm_scmi: Free mailbox channels if probe fails")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index f515b192c1bd..ddd026b05300 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -3328,7 +3328,7 @@ static int scmi_probe(struct platform_device *pdev)
dev_err(dev, "%s", err_str);
return 0;
}
- goto notification_exit;
+ goto raw_mode_cleanup;
}
mutex_lock(&scmi_list_mutex);
@@ -3372,10 +3372,9 @@ static int scmi_probe(struct platform_device *pdev)
return 0;
-notification_exit:
+raw_mode_cleanup:
if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT))
scmi_raw_mode_cleanup(info->raw);
- scmi_notification_exit(&info->handle);
clear_dev_req_notifier:
blocking_notifier_chain_unregister(&scmi_requested_devices_nh,
&info->dev_req_nb);
@@ -3383,6 +3382,7 @@ static int scmi_probe(struct platform_device *pdev)
bus_unregister_notifier(&scmi_bus_type, &info->bus_nb);
clear_txrx_setup:
scmi_cleanup_txrx_channels(info);
+ scmi_notification_exit(&info->handle);
ida_free(&scmi_id, info->id);
out_err:
@@ -3405,11 +3405,13 @@ static void scmi_remove(struct platform_device *pdev)
list_del(&info->node);
mutex_unlock(&scmi_list_mutex);
- scmi_notification_exit(&info->handle);
-
blocking_notifier_chain_unregister(&scmi_requested_devices_nh,
&info->dev_req_nb);
+ /* Stop transport callbacks before tearing down notifications. */
+ scmi_cleanup_txrx_channels(info);
+ scmi_notification_exit(&info->handle);
+
mutex_lock(&info->protocols_mtx);
idr_destroy(&info->protocols);
mutex_unlock(&info->protocols_mtx);
@@ -3420,9 +3422,6 @@ static void scmi_remove(struct platform_device *pdev)
bus_unregister_notifier(&scmi_bus_type, &info->bus_nb);
- /* Safe to free channels since no more users */
- scmi_cleanup_txrx_channels(info);
-
ida_free(&scmi_id, info->id);
}
--
2.43.0
^ permalink raw reply related
* [PATCH 07/42] drm/mediatek: ddp_comp: Move internal component register in function
From: AngeloGioacchino Del Regno @ 2026-07-01 12:20 UTC (permalink / raw)
To: chunkuang.hu
Cc: p.zabel, airlied, simona, maarten.lankhorst, mripard, tzimmermann,
robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
dri-devel, linux-mediatek, devicetree, linux-kernel,
linux-arm-kernel, justin.yeh, jason-jh.lin, kernel
In-Reply-To: <20260701122057.19648-1-angelogioacchino.delregno@collabora.com>
In preparation for adding an helper serving the purpose of finally
removing duplicated code to check for internal/simple components,
and for improving human readability in the up coming refactoring,
move the internal/simple component registration logic to its own
mtk_ddp_comp_init_internal_comp() function.
This brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 55 +++++++++++++++----------
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
index d716fd9f8a70..2ba2123238b3 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
@@ -629,6 +629,38 @@ static void mtk_ddp_comp_clk_put(void *_clk)
clk_put(clk);
}
+static int mtk_ddp_comp_init_internal_comp(struct device *dev, struct device *comp_dev)
+{
+ struct device_node *comp_node = comp_dev->of_node;
+ struct mtk_ddp_comp_dev *priv;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->regs = devm_of_iomap(dev, comp_node, 0, NULL);
+ if (IS_ERR(priv->regs))
+ return PTR_ERR(priv->regs);
+
+ priv->clk = of_clk_get(comp_node, 0);
+ if (IS_ERR(priv->clk))
+ return PTR_ERR(priv->clk);
+
+ ret = devm_add_action_or_reset(dev, mtk_ddp_comp_clk_put, priv->clk);
+ if (ret)
+ return ret;
+
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+ ret = cmdq_dev_get_client_reg(comp_dev, &priv->cmdq_reg, 0);
+ if (ret)
+ dev_dbg(comp_dev, "get mediatek,gce-client-reg fail!\n");
+#endif
+ dev_set_drvdata(comp_dev, priv);
+
+ return 0;
+};
+
int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
struct mtk_drm_comp_list *hlist,
unsigned int comp_id)
@@ -636,7 +668,6 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
struct platform_device *comp_pdev;
struct mtk_ddp_comp *comp;
enum mtk_ddp_comp_type type;
- struct mtk_ddp_comp_dev *priv;
int ret;
if (comp_id >= DDP_COMPONENT_DRM_ID_MAX)
@@ -686,29 +717,9 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
type == MTK_DISP_DSI)
goto end;
- priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- priv->regs = devm_of_iomap(dev, node, 0, NULL);
- if (IS_ERR(priv->regs))
- return PTR_ERR(priv->regs);
-
- priv->clk = of_clk_get(node, 0);
- if (IS_ERR(priv->clk))
- return PTR_ERR(priv->clk);
-
- ret = devm_add_action_or_reset(dev, mtk_ddp_comp_clk_put, priv->clk);
+ ret = mtk_ddp_comp_init_internal_comp(dev, comp->dev);
if (ret)
return ret;
-
-#if IS_REACHABLE(CONFIG_MTK_CMDQ)
- ret = cmdq_dev_get_client_reg(comp->dev, &priv->cmdq_reg, 0);
- if (ret)
- dev_dbg(comp->dev, "get mediatek,gce-client-reg fail!\n");
-#endif
-
- platform_set_drvdata(comp_pdev, priv);
end:
hash_add(hlist->ddp_list, &comp->lnode, comp->id);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 23/42] dt-bindings: display: mediatek: Introduce Digital Video Output HW
From: AngeloGioacchino Del Regno @ 2026-07-01 16:53 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: krzk+dt, dri-devel, linux-kernel, p.zabel, kernel, tzimmermann,
chunkuang.hu, simona, linux-arm-kernel, jason-jh.lin, airlied,
conor+dt, maarten.lankhorst, linux-mediatek, matthias.bgg,
mripard, devicetree, justin.yeh
In-Reply-To: <178291581273.4115171.8214844308967079622.robh@kernel.org>
On 7/1/26 16:23, Rob Herring (Arm) wrote:
>
> On Wed, 01 Jul 2026 14:20:38 +0200, AngeloGioacchino Del Regno wrote:
>> Add documentation for the Digital Video Output (DVO) IP found in
>> the newer generation SoCs MT8196, MT8189 and their variants.
>>
>> This is effectively a more capable block replacing the DisplayPort
>> Interface (DPI/DP_INTF) one found in older SoCs.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>> .../display/mediatek/mediatek,mt8196-dvo.yaml | 142 ++++++++++++++++++
>> 1 file changed, 142 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml
>>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
Those errors on literally all bindings are quite embarassing. Oops.
Already fixed locally, but since this is a huge series, I will allow some time
for reviews before compulsively pushing a v2.
Cheers,
Angelo
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: ignoring, error in schema: properties: compatible
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.yaml: properties:compatible: [{'const': 'mediatek,mt8189-dp-dvo'}, {'const': 'mediatek,mt8189-edp-dvo'}, {'const': 'mediatek,mt8196-edp-dvo'}] is not of type 'object', 'boolean'
> Traceback (most recent call last):
> File "/usr/local/bin/dt-doc-validate", line 8, in <module>
> sys.exit(main())
> ~~~~^^
> File "/usr/local/lib/python3.13/dist-packages/dtschema/doc_validate.py", line 66, in main
> ret |= check_doc(f)
> ~~~~~~~~~^^^
> File "/usr/local/lib/python3.13/dist-packages/dtschema/doc_validate.py", line 37, in check_doc
> dtsch.check_schema_refs()
> ~~~~~~~~~~~~~~~~~~~~~~~^^
> File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 242, in check_schema_refs
> self._check_schema_refs(resolver, self)
> ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
> File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 212, in _check_schema_refs
> self._check_schema_refs(resolver, v, parent=k, is_common=is_common,
> ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> has_constraint=has_constraint)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 212, in _check_schema_refs
> self._check_schema_refs(resolver, v, parent=k, is_common=is_common,
> ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> has_constraint=has_constraint)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 203, in _check_schema_refs
> ref_sch = resolver.lookup(schema['$ref']).contents
> ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
> File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 682, in lookup
> retrieved = self._registry.get_or_retrieve(uri)
> File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 422, in get_or_retrieve
> registry = self.crawl()
> File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 500, in crawl
> id = resource.id()
> File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 231, in id
> id = self._specification.id_of(self.contents)
> File "/usr/local/lib/python3.13/dist-packages/referencing/jsonschema.py", line 50, in _dollar_id
> return contents.get("$id")
> ^^^^^^^^^^^^
> AttributeError: 'list' object has no attribute 'get'
> Documentation/devicetree/bindings/display/mediatek/mediatek,mt8196-dvo.example.dtb: /example-0/dvo@324c0000: failed to match any schema with compatible: ['mediatek,mt8196-edp-dvo']
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260701122057.19648-24-angelogioacchino.delregno@collabora.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>
^ permalink raw reply
* Re: [PATCH v3 1/3] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Leonardo Bras @ 2026-07-01 16:53 UTC (permalink / raw)
To: Bradley Morgan
Cc: Leonardo Bras, Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, Quentin Perret, Vincent Donnefort, Gavin Shan,
Alexandru Elisei, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <5105C9D2-C708-452E-BA61-F22083A33C74@grrlz.net>
On Wed, Jul 01, 2026 at 05:40:46PM +0100, Bradley Morgan wrote:
> On July 1, 2026 5:05:53 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
> wrote:
> >On Wed, Jun 24, 2026 at 04:00:26PM +0000, Bradley Morgan wrote:
> >> pKVM keeps its own mapping list for stage 2 operations. Its flush path
> >> uses that list directly, so it lost the PTE attribute check done by the
> >> generic stage 2 walker.
> >>
> >> Record whether a mapping is cacheable and skip cache maintenance for
> >> mappings that are not cacheable.
> >>
> >> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> >> Signed-off-by: Bradley Morgan <include@grrlz.net>
> >> ---
> >> arch/arm64/kvm/pkvm.c | 51 ++++++++++++++++++++++++++++++++++---------
> >> 1 file changed, 41 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> >> index 428723b1b0f5..ca6e823028c2 100644
> >> --- a/arch/arm64/kvm/pkvm.c
> >> +++ b/arch/arm64/kvm/pkvm.c
> >> @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct pkvm_mapping
> >*m)
> >> return m->gfn * PAGE_SIZE;
> >> }
> >>
> >> +#define PKVM_MAPPING_NR_PAGES_MASK GENMASK_ULL(47, 0)
> >> +#define PKVM_MAPPING_CACHEABLE BIT_ULL(48)
> >
> >Out of curiosity here, why do you choose to use bit 48 here instead of,
> >let's say, bit 63?
> >
> >(I know it makes absolutely no difference to inner working here, as there
> >should probably not be 2^48 pages in one mapping.)
> >
> >Thanks!
> >Leo
>
>
> sup Leo, here's a quote from maz
Hi Bradley,
>
> "This thing is already big enough, let's not add a bool right in the
> middle (use pahole to find out why this is bad).
I suppose you proposed to add a bool into a struct, maybe?
It would screw the struct alignment.
> Given that nr_pages
> is for a range, and that the minimum page size uses 12 bits, the
> largest number of pages you can have here is 56-12=48 bit wide. That's
> another 16 bits worth of flags you can use."
Humm, makes sense.
And since he mentions 16 bits worth of flags, you start by using the 48th
bit. Ok, got your rationale.
(I would possibly start with the 63, though, but that's more on personal
taste)
>
> this should just clarify things, any questions, feel more than free to ask!
>
> (btw V4 is coming soon)
Thanks!
Leo
>
> >> +
> >> +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
> >> +{
> >> + return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> >> +}
> >> +
> >> +static bool pkvm_mapping_is_cacheable(struct pkvm_mapping *m)
> >> +{
> >> + return m->nr_pages & PKVM_MAPPING_CACHEABLE;
> >> +}
> >> +
> >> +static void pkvm_mapping_set_nr_pages(struct pkvm_mapping *m, u64
> >nr_pages,
> >> + bool cacheable)
> >> +{
> >> + WARN_ON_ONCE(nr_pages & ~PKVM_MAPPING_NR_PAGES_MASK);
> >> +
> >> + m->nr_pages = nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> >> + if (cacheable)
> >> + m->nr_pages |= PKVM_MAPPING_CACHEABLE;
> >> +}
> >> +
> >> static u64 __pkvm_mapping_end(struct pkvm_mapping *m)
> >> {
> >> - return (m->gfn + m->nr_pages) * PAGE_SIZE - 1;
> >> + return (m->gfn + pkvm_mapping_nr_pages(m)) * PAGE_SIZE - 1;
> >> }
> >>
> >> INTERVAL_TREE_DEFINE(struct pkvm_mapping, node, u64, __subtree_last,
> >> @@ -350,7 +373,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct
> >kvm_pgtable *pgt, u64 start, u64
> >> continue;
> >>
> >> page = pfn_to_page(mapping->pfn);
> >> - WARN_ON_ONCE(mapping->nr_pages != 1);
> >> + WARN_ON_ONCE(pkvm_mapping_nr_pages(mapping) != 1);
> >> unpin_user_pages_dirty_lock(&page, 1, true);
> >> account_locked_vm(kvm->mm, 1, false);
> >> pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> >> @@ -369,7 +392,7 @@ static int __pkvm_pgtable_stage2_unshare(struct
> >kvm_pgtable *pgt, u64 start, u64
> >>
> >> for_each_mapping_in_range_safe(pgt, start, end, mapping) {
> >> ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
> >> - mapping->nr_pages);
> >> + pkvm_mapping_nr_pages(mapping));
> >> if (WARN_ON(ret))
> >> return ret;
> >> pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> >> @@ -448,7 +471,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt,
> >u64 addr, u64 size,
> >> * permission faults are handled in the relax_perms() path.
> >> */
> >> if (mapping) {
> >> - if (size == (mapping->nr_pages * PAGE_SIZE))
> >> + if (size == (pkvm_mapping_nr_pages(mapping) * PAGE_SIZE))
> >> return -EAGAIN;
> >>
> >> /*
> >> @@ -472,7 +495,9 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt,
> >u64 addr, u64 size,
> >> swap(mapping, cache->mapping);
> >> mapping->gfn = gfn;
> >> mapping->pfn = pfn;
> >> - mapping->nr_pages = size / PAGE_SIZE;
> >> + pkvm_mapping_set_nr_pages(mapping, size / PAGE_SIZE,
> >> + !(prot & (KVM_PGTABLE_PROT_DEVICE |
> >> + KVM_PGTABLE_PROT_NORMAL_NC)));
> >> pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
> >>
> >> return ret;
> >> @@ -503,7 +528,7 @@ int pkvm_pgtable_stage2_wrprotect(struct kvm_pgtable
> >*pgt, u64 addr, u64 size)
> >> lockdep_assert_held(&kvm->mmu_lock);
> >> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> >> ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
> >> - mapping->nr_pages);
> >> + pkvm_mapping_nr_pages(mapping));
> >> if (WARN_ON(ret))
> >> break;
> >> }
> >> @@ -517,9 +542,13 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable
> >*pgt, u64 addr, u64 size)
> >> struct pkvm_mapping *mapping;
> >>
> >> lockdep_assert_held(&kvm->mmu_lock);
> >> - for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> >> + for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> >> + if (!pkvm_mapping_is_cacheable(mapping))
> >> + continue;
> >> +
> >> __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
> >> - PAGE_SIZE * mapping->nr_pages);
> >> + PAGE_SIZE * pkvm_mapping_nr_pages(mapping));
> >> + }
> >>
> >> return 0;
> >> }
> >> @@ -536,8 +565,10 @@ bool pkvm_pgtable_stage2_test_clear_young(struct
> >kvm_pgtable *pgt, u64 addr, u64
> >>
> >> lockdep_assert_held(&kvm->mmu_lock);
> >> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> >> - young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
> >> - mapping->nr_pages, mkold);
> >> + young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest,
> >> + handle, mapping->gfn,
> >> + pkvm_mapping_nr_pages(mapping),
> >> + mkold);
> >>
> >> return young;
> >> }
> >> --
> >> 2.53.0
> >>
> >
>
> Thanks!
^ permalink raw reply
* [PATCH v7 04/11] arm64: dts: ti: k3-am62p-verdin: Fix wkup R5F memory region size
From: Markus Schneider-Pargmann (TI) @ 2026-07-01 12:39 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260701-topic-am62a-ioddr-dt-v6-19-v7-0-e9db8b16821a@baylibre.com>
The wkup_r5fss0_core0_memory_region was reserved with
0x01e00000 but the MCU SDK linker for the wkup R5F firmware on
AM62P defines the DM code/data DDR footprint differently:
/* DDR for DM R5F code/data [ size 27 MiB + 396 KB ] */
DDR : ORIGIN = 0x9CAA5000 LENGTH = 0x1B63000
which results in an end at 0x9e608000. For this memory region which
starts at 0x9c900000 this means a length of:
0x9e608000 - 0x9c900000 = 0x1d08000
Link: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/linker.cmd
Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
index 7ee894d59113aa727d41b7ecd6b2bc7e12760823..8a5ff5c457579c7b1be7157d235fd4b4e5c6af11 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
@@ -170,7 +170,7 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
wkup_r5fss0_core0_memory_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01e00000>;
+ reg = <0x00 0x9c900000 0x00 0x01d08000>;
no-map;
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/3] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-07-01 16:54 UTC (permalink / raw)
To: Leonardo Bras
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, Gavin Shan, Alexandru Elisei,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <akVGDoI9FltrVduP@LeoBrasDK>
On July 1, 2026 5:53:34 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
wrote:
>On Wed, Jul 01, 2026 at 05:40:46PM +0100, Bradley Morgan wrote:
>> On July 1, 2026 5:05:53 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
>> wrote:
>> >On Wed, Jun 24, 2026 at 04:00:26PM +0000, Bradley Morgan wrote:
>> >> pKVM keeps its own mapping list for stage 2 operations. Its flush
>path
>> >> uses that list directly, so it lost the PTE attribute check done by
>the
>> >> generic stage 2 walker.
>> >>
>> >> Record whether a mapping is cacheable and skip cache maintenance for
>> >> mappings that are not cacheable.
>> >>
>> >> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
>> >> Signed-off-by: Bradley Morgan <include@grrlz.net>
>> >> ---
>> >> arch/arm64/kvm/pkvm.c | 51
>++++++++++++++++++++++++++++++++++---------
>> >> 1 file changed, 41 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
>> >> index 428723b1b0f5..ca6e823028c2 100644
>> >> --- a/arch/arm64/kvm/pkvm.c
>> >> +++ b/arch/arm64/kvm/pkvm.c
>> >> @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct
>pkvm_mapping
>> >*m)
>> >> return m->gfn * PAGE_SIZE;
>> >> }
>> >>
>> >> +#define PKVM_MAPPING_NR_PAGES_MASK GENMASK_ULL(47, 0)
>> >> +#define PKVM_MAPPING_CACHEABLE BIT_ULL(48)
>> >
>> >Out of curiosity here, why do you choose to use bit 48 here instead of,
>> >let's say, bit 63?
>> >
>> >(I know it makes absolutely no difference to inner working here, as
>there
>> >should probably not be 2^48 pages in one mapping.)
>> >
>> >Thanks!
>> >Leo
>>
>>
>> sup Leo, here's a quote from maz
>
>Hi Bradley,
>
>>
>> "This thing is already big enough, let's not add a bool right in the
>> middle (use pahole to find out why this is bad).
>
>I suppose you proposed to add a bool into a struct, maybe?
>It would screw the struct alignment.
yep, crappy old me
>> Given that nr_pages
>> is for a range, and that the minimum page size uses 12 bits, the
>> largest number of pages you can have here is 56-12=48 bit wide. That's
>> another 16 bits worth of flags you can use."
>
>Humm, makes sense.
>And since he mentions 16 bits worth of flags, you start by using the 48th
>bit. Ok, got your rationale.
>
>(I would possibly start with the 63, though, but that's more on personal
>taste)
48 won't make the world blow up :)
>>
>> this should just clarify things, any questions, feel more than free to
>ask!
>>
>> (btw V4 is coming soon)
>
>Thanks!
>Leo
>
>>
>> >> +
>> >> +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
>> >> +{
>> >> + return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
>> >> +}
>> >> +
>> >> +static bool pkvm_mapping_is_cacheable(struct pkvm_mapping *m)
>> >> +{
>> >> + return m->nr_pages & PKVM_MAPPING_CACHEABLE;
>> >> +}
>> >> +
>> >> +static void pkvm_mapping_set_nr_pages(struct pkvm_mapping *m, u64
>> >nr_pages,
>> >> + bool cacheable)
>> >> +{
>> >> + WARN_ON_ONCE(nr_pages & ~PKVM_MAPPING_NR_PAGES_MASK);
>> >> +
>> >> + m->nr_pages = nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
>> >> + if (cacheable)
>> >> + m->nr_pages |= PKVM_MAPPING_CACHEABLE;
>> >> +}
>> >> +
>> >> static u64 __pkvm_mapping_end(struct pkvm_mapping *m)
>> >> {
>> >> - return (m->gfn + m->nr_pages) * PAGE_SIZE - 1;
>> >> + return (m->gfn + pkvm_mapping_nr_pages(m)) * PAGE_SIZE - 1;
>> >> }
>> >>
>> >> INTERVAL_TREE_DEFINE(struct pkvm_mapping, node, u64, __subtree_last,
>> >> @@ -350,7 +373,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct
>> >kvm_pgtable *pgt, u64 start, u64
>> >> continue;
>> >>
>> >> page = pfn_to_page(mapping->pfn);
>> >> - WARN_ON_ONCE(mapping->nr_pages != 1);
>> >> + WARN_ON_ONCE(pkvm_mapping_nr_pages(mapping) != 1);
>> >> unpin_user_pages_dirty_lock(&page, 1, true);
>> >> account_locked_vm(kvm->mm, 1, false);
>> >> pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
>> >> @@ -369,7 +392,7 @@ static int __pkvm_pgtable_stage2_unshare(struct
>> >kvm_pgtable *pgt, u64 start, u64
>> >>
>> >> for_each_mapping_in_range_safe(pgt, start, end, mapping) {
>> >> ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
>> >> - mapping->nr_pages);
>> >> + pkvm_mapping_nr_pages(mapping));
>> >> if (WARN_ON(ret))
>> >> return ret;
>> >> pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
>> >> @@ -448,7 +471,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable
>*pgt,
>> >u64 addr, u64 size,
>> >> * permission faults are handled in the relax_perms() path.
>> >> */
>> >> if (mapping) {
>> >> - if (size == (mapping->nr_pages * PAGE_SIZE))
>> >> + if (size == (pkvm_mapping_nr_pages(mapping) * PAGE_SIZE))
>> >> return -EAGAIN;
>> >>
>> >> /*
>> >> @@ -472,7 +495,9 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable
>*pgt,
>> >u64 addr, u64 size,
>> >> swap(mapping, cache->mapping);
>> >> mapping->gfn = gfn;
>> >> mapping->pfn = pfn;
>> >> - mapping->nr_pages = size / PAGE_SIZE;
>> >> + pkvm_mapping_set_nr_pages(mapping, size / PAGE_SIZE,
>> >> + !(prot & (KVM_PGTABLE_PROT_DEVICE |
>> >> + KVM_PGTABLE_PROT_NORMAL_NC)));
>> >> pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
>> >>
>> >> return ret;
>> >> @@ -503,7 +528,7 @@ int pkvm_pgtable_stage2_wrprotect(struct
>kvm_pgtable
>> >*pgt, u64 addr, u64 size)
>> >> lockdep_assert_held(&kvm->mmu_lock);
>> >> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
>> >> ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
>> >> - mapping->nr_pages);
>> >> + pkvm_mapping_nr_pages(mapping));
>> >> if (WARN_ON(ret))
>> >> break;
>> >> }
>> >> @@ -517,9 +542,13 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable
>> >*pgt, u64 addr, u64 size)
>> >> struct pkvm_mapping *mapping;
>> >>
>> >> lockdep_assert_held(&kvm->mmu_lock);
>> >> - for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
>> >> + for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
>> >> + if (!pkvm_mapping_is_cacheable(mapping))
>> >> + continue;
>> >> +
>> >> __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
>> >> - PAGE_SIZE * mapping->nr_pages);
>> >> + PAGE_SIZE * pkvm_mapping_nr_pages(mapping));
>> >> + }
>> >>
>> >> return 0;
>> >> }
>> >> @@ -536,8 +565,10 @@ bool pkvm_pgtable_stage2_test_clear_young(struct
>> >kvm_pgtable *pgt, u64 addr, u64
>> >>
>> >> lockdep_assert_held(&kvm->mmu_lock);
>> >> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
>> >> - young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
>> >> - mapping->nr_pages, mkold);
>> >> + young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest,
>> >> + handle, mapping->gfn,
>> >> + pkvm_mapping_nr_pages(mapping),
>> >> + mkold);
>> >>
>> >> return young;
>> >> }
>> >> --
>> >> 2.53.0
>> >>
>> >
>>
>> Thanks!
>
Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Alexandre Belloni @ 2026-07-01 15:06 UTC (permalink / raw)
To: Markus Probst
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <20260630-rtc_s35390a_int1-v1-1-1b2239e16be2@posteo.de>
On 30/06/2026 19:22:21+0000, Markus Probst wrote:
> Synology NAS devices use the output pin for interrupt signal 1 to wake up
> the system.
>
> Move devicetree bindings for sii,s35390a into its own file.
> Add sii,wakealarm-output-pin property to enable the use of the output
> pin for interrupt signal 1 for the wake alarm, which makes it possible to
> set an wake alarm on Synology NAS devices.
>
> Signed-off-by: Markus Probst <markus.probst@posteo.de>
> ---
> .../devicetree/bindings/rtc/sii,s35390a.yaml | 54 ++++++++++++++++++++++
> .../devicetree/bindings/rtc/trivial-rtc.yaml | 3 --
> MAINTAINERS | 1 +
> include/dt-bindings/rtc/s35390a.h | 9 ++++
> 4 files changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> new file mode 100644
> index 000000000000..31a578673870
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/sii,s35390a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: S-35390A 2-WIRE REAL-TIME CLOCK
> +
> +maintainers:
> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
> +
> +description:
> + The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
> + very low current consumption in the wide range of operation voltage.
> +
> +allOf:
> + - $ref: rtc.yaml#
> +
> +properties:
> + compatible:
> + const: sii,s35390a
> +
> + reg:
> + maxItems: 1
> +
> + sii,wakealarm-output-pin:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [1, 2]
> + description: |
> + The output pin to wake up the system.
> + Default will use the output pin for interrupt signal 2.
> + <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
> + <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
> +
Ideally, we'd get a proper pinctrl driver part for this because what
happens if you want interrupts on both pin or clock output on both pins
or any combination of interrupts and clocks?
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v7 00/11] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann (TI) @ 2026-07-01 12:39 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
Hi,
Split the firmware memory region in more specific parts so it is better
described where which information is stored. Specifically the LPM metadata
region is important as bootloader software like U-Boot has to know where
that data is to be able to read that data and resume from RAM.
The bindings are already applied. The remaining patches use the new
layout for the platforms that are capable to support IO+DDR. For IO+DDR
the new layout is necessary as it defines the location of the LPM
metadata.
Additionally the two important devicetree nodes for resuming from IO+DDR
have the bootph-pre-ram flag added as this data needs to be read before
the RAM is in use.
The changes in this series were suggested as part of the IO+DDR u-boot series:
https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
Note that concerns about uboot fixup of memory region fixups were
discussed here:
https://lore.kernel.org/r/DJD1Y3G9S1SP.2GHOZ5X4RYJFA@baylibre.com
Best
Markus
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
Changes in v7:
- Rebase to v7.1-rc1
- Fix commit messages
- Link to v6: https://lore.kernel.org/r/20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com
Changes in v6:
- Added fixes for the length of the wkup_r5fss0_core0_memory_region.
Thanks Francesco for pointing that out. am62a firmware is shorter than
am62p firmware. I calculated both and fixed all devicetrees using
them. All patches have different Fixes tags so I kept them separate.
- Fixed the length of the split memory layout as well.
- Removed the double definition of memory regions for the var-som board.
- Link to v5: https://lore.kernel.org/r/20260601-topic-am62a-ioddr-dt-v6-19-v5-0-3856a023aff2@baylibre.com
Changes in v5:
- Move all changes into k3-am62a/p-ti-ipc-firmware.dtsi
- Dropped the patch that adds bootph-pre-ram to k3-am62a stuff as it is
already present in k3-am62d2-evm.dts and got moved into the
firmware.dtsi file which covers am62a as well then.
- Link to v4: https://lore.kernel.org/r/20260429-topic-am62a-ioddr-dt-v6-19-v4-0-fc27d6ac753c@baylibre.com
Changes in v4:
- Rebased to v7.1-rc1
- Dropped all already applied patches that are the bindings and the
initial introduction of memory-region-names
- Link to v3: https://lore.kernel.org/r/20260318-topic-am62a-ioddr-dt-v6-19-v3-0-c41473cb23c3@baylibre.com
Changes in v3:
- Squash the enforcement of the memory-region-names requirement in the
patch adding the memory-region-names, as suggested.
- Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
Changes in v2:
- Make memory-region-names required if memory-region is present
- Fixup memory-region and memory-region-names conditions. Require either
2 or 6 regions for memory-region and memory-region-names
- Reword and restructure the binding documentation for memory-region and
memory-region-names
- Add memory-region-names to all uses of memory-region
- Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
---
Markus Schneider-Pargmann (TI) (11):
arm64: dts: ti: k3-am62a-phycore-som: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62d2-evm: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62a7-sk: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62p-verdin: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62p5-sk: Fix wkup R5F memory region size
arm64: dts: ti: var-som-am62p: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62a-ti-ipc-firmware: Move wkup reserved memory
arm64: dts: ti: k3-am62p-ti-ipc-firmware: Move wkup reserved memory
arm64: dts: ti: k3-am62a-ti-ipc-firmware: Split r5f memory region
arm64: dts: ti: k3-am62p-ti-ipc-firmware: Split r5f memory region
arm64: dts: ti: k3-am62p-ti-ipc-firmware: Add r5f nodes to pre-ram bootphase
arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi | 12 ------
.../boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi | 48 +++++++++++++++++++++-
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 12 ------
arch/arm64/boot/dts/ti/k3-am62d2-evm.dts | 17 --------
.../boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi | 48 +++++++++++++++++++++-
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 12 ------
arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 12 ------
arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi | 12 ------
8 files changed, 92 insertions(+), 81 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260210-topic-am62a-ioddr-dt-v6-19-0da7712081d7
Best regards,
--
Markus Schneider-Pargmann (TI) <msp@baylibre.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: mediatek,tphy: Add support for MT8189 SoC
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Chunfeng Yun, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger
Cc: kernel, linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-tphy-v1-1-5848a2be8303@collabora.com>
On 7/1/26 17:36, Louis-Alexis Eyraud wrote:
> Add a compatible string for the MediaTek MT8189 SoC, that integrates a
> MediaTek generic T-PHY version 3.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: mediatek,uart-dma: add support for MT8189 SoC
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Sean Wang, Vinod Koul, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Long Cheng
Cc: kernel, dmaengine, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-uart-dma-v1-1-c7106216a40d@collabora.com>
On 7/1/26 17:47, Louis-Alexis Eyraud wrote:
> Add the compatible string for the APDMA IP found in MT8189 SoC,
> that supports 35-bits addressing as MT6985 SoC.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: PCI: mediatek-gen3: Add support for MT8189 SoC
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Ryder Lee, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Jianjun Wang
Cc: kernel, linux-pci, linux-mediatek, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-pcie-v1-1-7c7a65087654@collabora.com>
On 7/1/26 17:27, Louis-Alexis Eyraud wrote:
> Add compatible for MT8189 PCIe Gen3 controller, that is compatible with
> the one found MT8192.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ 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