* [PATCH 01/37] drm/connector: split drmm_connector_hdmi_init() in 3 parts
From: Luca Ceresoli @ 2026-05-19 10:37 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Inki Dae,
Jagan Teki, Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel, Luca Ceresoli
In-Reply-To: <20260519-drm-bridge-hotplug-v1-0-45e2bdb3dfb4@bootlin.com>
In preparation for adding a dynamic variant of drmm_connector_hdmi_init(),
split reusable parts of the code to subfunctions.
drmm_connector_hdmi_init() currently has 3 sections:
1. sanity checks
2. call drmm_connector_init()
3. initialize HDMI-specific fields not initialized at step 2
Split 1 and 3 to new functions, reusable independently.
No functional changes. Just moving code around.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
drivers/gpu/drm/drm_connector.c | 105 +++++++++++++++++++++++++---------------
1 file changed, 65 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3fa4d2082cd7..37ed73300a18 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -542,44 +542,13 @@ int drmm_connector_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drmm_connector_init);
-/**
- * drmm_connector_hdmi_init - Init a preallocated HDMI connector
- * @dev: DRM device
- * @connector: A pointer to the HDMI connector to init
- * @vendor: HDMI Controller Vendor name
- * @product: HDMI Controller Product name
- * @funcs: callbacks for this connector
- * @hdmi_funcs: HDMI-related callbacks for this connector
- * @connector_type: user visible type of the connector
- * @ddc: optional pointer to the associated ddc adapter
- * @supported_formats: Bitmask of @drm_output_color_format listing supported output formats
- * @max_bpc: Maximum bits per char the HDMI connector supports
- *
- * Initialises a preallocated HDMI connector. Connectors can be
- * subclassed as part of driver connector objects.
- *
- * Cleanup is automatically handled with a call to
- * drm_connector_cleanup() in a DRM-managed action.
- *
- * The connector structure should be allocated with drmm_kzalloc().
- *
- * The @drm_connector_funcs.destroy hook must be NULL.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drmm_connector_hdmi_init(struct drm_device *dev,
- struct drm_connector *connector,
- const char *vendor, const char *product,
- const struct drm_connector_funcs *funcs,
- const struct drm_connector_hdmi_funcs *hdmi_funcs,
- int connector_type,
- struct i2c_adapter *ddc,
- unsigned long supported_formats,
- unsigned int max_bpc)
+static int drm_connector_hdmi_sanity_checks(struct drm_connector *connector,
+ const char *vendor, const char *product,
+ const struct drm_connector_hdmi_funcs *hdmi_funcs,
+ int connector_type,
+ unsigned long supported_formats,
+ unsigned int max_bpc)
{
- int ret;
-
if (!vendor || !product)
return -EINVAL;
@@ -606,10 +575,15 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
!hdmi_funcs->hdmi.write_infoframe)
return -EINVAL;
- ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
- if (ret)
- return ret;
+ return 0;
+}
+static void drm_connector_hdmi_init(struct drm_connector *connector,
+ const char *vendor, const char *product,
+ const struct drm_connector_hdmi_funcs *hdmi_funcs,
+ unsigned long supported_formats,
+ unsigned int max_bpc)
+{
connector->hdmi.supported_formats = supported_formats;
strtomem_pad(connector->hdmi.vendor, vendor, 0);
strtomem_pad(connector->hdmi.product, product, 0);
@@ -628,6 +602,57 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
drm_connector_attach_hdr_output_metadata_property(connector);
connector->hdmi.funcs = hdmi_funcs;
+}
+
+/**
+ * drmm_connector_hdmi_init - Init a preallocated HDMI connector
+ * @dev: DRM device
+ * @connector: A pointer to the HDMI connector to init
+ * @vendor: HDMI Controller Vendor name
+ * @product: HDMI Controller Product name
+ * @funcs: callbacks for this connector
+ * @hdmi_funcs: HDMI-related callbacks for this connector
+ * @connector_type: user visible type of the connector
+ * @ddc: optional pointer to the associated ddc adapter
+ * @supported_formats: Bitmask of @drm_output_color_format listing supported output formats
+ * @max_bpc: Maximum bits per char the HDMI connector supports
+ *
+ * Initialises a preallocated HDMI connector. Connectors can be
+ * subclassed as part of driver connector objects.
+ *
+ * Cleanup is automatically handled with a call to
+ * drm_connector_cleanup() in a DRM-managed action.
+ *
+ * The connector structure should be allocated with drmm_kzalloc().
+ *
+ * The @drm_connector_funcs.destroy hook must be NULL.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drmm_connector_hdmi_init(struct drm_device *dev,
+ struct drm_connector *connector,
+ const char *vendor, const char *product,
+ const struct drm_connector_funcs *funcs,
+ const struct drm_connector_hdmi_funcs *hdmi_funcs,
+ int connector_type,
+ struct i2c_adapter *ddc,
+ unsigned long supported_formats,
+ unsigned int max_bpc)
+{
+ int ret;
+
+ ret = drm_connector_hdmi_sanity_checks(connector, vendor, product, hdmi_funcs,
+ connector_type, supported_formats, max_bpc);
+ if (ret)
+ return ret;
+
+ ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
+ if (ret)
+ return ret;
+
+ drm_connector_hdmi_init(connector, vendor, product,
+ hdmi_funcs, supported_formats, max_bpc);
return 0;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 00/37] drm bridge hotplug
From: Luca Ceresoli @ 2026-05-19 10:37 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Inki Dae,
Jagan Teki, Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel, Luca Ceresoli
Hello,
this series adds support for Linux-based devices with a DRM pipeline whose
final components, including one or more bridges, can be hot-plugged and
hot-unplugged.
TL;DR:
* This new approach is totally different from the one proposed in the
past [0], and the code is an almost completely rewrite
* If you already know the use case, feel free to skip to the "Design"
section below
Use case
========
This series targets as its first use case a professional product (GE SUNH)
that is composed of a "main" part, with the main SoC and able to work
autonomously with limited features, and an optional "add-on" that enables
more features by adding more hardware peripherals.
The hotplug connector has a MIPI DSI bus. The addon has a DSI-to-LVDS
bridge and an LVDS panel attached to it. Different addon models can have
different components. As a consequence, a DRM bridge must be added and
removed at runtime without tearing down the whole card. This is currently
not possible, and this series enables it.
DRM already supports pipelines whose display can be removed, but all the
components preceding it (all the display controller and any bridges) are
assumed to be fixed and cannot be plugged, removed or modified at
runtime. Additionally, dynamic drm_connectors are supported for DP MST.
This picture summarizes the DRM structure implemented by this series:
.------------------------.
| DISPLAY CONTROLLER |
| .---------. .------. |
| | ENCODER |<--| CRTC | |
| '---------' '------' |
'------|-----------------'
| MACHANICAL
|DSI HOTPLUG
V CONNECTOR
.---------. .--. .-. .---------. .-------.
| 0 to N | | _| _| | | 1 to N | | |
| BRIDGES |--DSI-->||_ |_ |--DSI-->| BRIDGES |--LVDS-->| PANEL |
| | | | | | | | | |
'---------' '--' '-' '---------' '-------'
[--- fixed components --] [----------- removable add-on -----------]
The video bus is MIPI DSI in the example and in the implementation provided
by this series, but the implementation is meant to allow generalization to
other video busses without native hotplug support, such as parallel video
and LVDS. Addons which terminate with a HDMI/DP connector are possible too.
== Design
The old approach [0] was based on a hotplug-bridge driver, connected
between the last fixed bridge and the first removable bridge.
That approach has been rejected, and this new approach is based on a
central place to handle DRM hotplug, not a specific driver.
The drm_bridge_connector is nowadays the recommended way to implement DRM
connectors when a chain of bridges is used. It takes care of adding the
drm_connector when the pipeline is composed by an arbitrarily long chain of
bridges, which it scans to properly implement the drm_connector
operations.
As such the drm_bridge_connector looked like the ideal component to
implement DRM bridge hotplug.
This series augments the drm_bridge_connector code to be able to create and
destroy the drm_connector reacting on hot(un)plug events.
== Series description
This series has many preparatory patches: to make the drm_bridge_connector
code allocate the drm_connector dynamically and to prepare various other
parts of the involved DRM code.
In current code the last bridge in the encoder chain is always assumed to
complete the pipeline. There is no way for a bridge to tell "I'm currently
the last bridge in the encoder chain, but I need an next bridge to
work". This series has some patches to allow such a behaviour:
* bridges can now report whether they conclude the pipeline or not (I
propose the "tail bridge" naming to tell this)
* returning -EPROBE_DEFER on bridge attach is not considered a hard error
anymore, it's normal when the next bridge is needed but not yet present
Compared to the hotplug-bridge approach, now bridge drivers need a bit of
adaptation in order to support that the following bridge is
hotpluggable. So there are a few changes to the samsung-dsim bridge driver,
which in the hardware I'm working on is the last fixed bridge.
Finally, as the current drm_bridge_connector API is unable to support
hotplug, a new API is added to enable the new features. This makes existing
drivers not affected by the changes. The last patch shows to changes needed
to an encoder driver to switch to the new API enabling hotplug support.
== Series layout
1. Add a dynamic variant of drm_connector_hdmi_init()
(needed for the bridge-connector to allocate the connector dynamically)
* drm/connector: split drmm_connector_hdmi_init() in 3 parts
* drm/connector: add drm_connector_hdmi_dynamic_init()
2. bridge-connector: split the long drm_bridge_connector_init() in various
parts in preparation to be called in different ways
* drm/display: bridge-connector: rename variable for consistency
* drm/display: bridge-connector: store the drm_device pointer
* drm/display: bridge-connector: split code creating the connector to a subfunction
* drm/display: bridge-connector: use a drm_bridge_connector internally, not a drm_connector
* drm/display: bridge-connector: extract drm_bridge_connector_get_bridges()
* drm/display: bridge-connector: return int from drm_bridge_connector_get_bridges()
* drm/display: bridge-connector: extract drm_bridge_connector_init_hdmi_audio_cec()
* drm/display: bridge-connector: return int from drm_bridge_connector_init_hdmi_audio_cec()
* drm/display: bridge-connector: return int from drm_bridge_connector_add_connector()
3. bridge-connector: create the drm_connector dynamically
* drm/display: bridge-connector: hoist error management to common code
* drm/display: bridge-connector: move drm_bridge_connector_put_bridges() definition eariler
* drm/display: bridge-connector: add non-drmm variant of drm_bridge_connector_put_bridges()
* drm/display: bridge-connector: allocate the connector dynamically
* drm/display: bridge-connector: move per-connector fields to the dynamic connector
* drm/display: bridge-connector: protect dynconn creation and destruction with a mutex
4. samsung-dsim: prepare driver to work when the following bridge is hotpluggable
* drm/bridge: samsung-dsim: remove the panel_bridge on host_detach
* drm/bridge: samsung-dsim: move drm_bridge_add() call to probe
* drm/bridge: samsung-dsim: attach: return -EPROBE_DEFER is next bridge not yet available
5. Misc preparation work
* drm/bridge: initialize chain_node list head on allocation
* drm/bridge: initialize chain_node list head on detach and attach errors
6. drm_bridge: stop pipeline when a bridge is removed
* drm/encoder: add drm_encoder_cleanup_from()
* drm/atomic: move drm_atomic_helper_disable_all() and drm_atomic_helper_shutdown() from drm_atomic_helper to drm_atomic
* drm/bridge: shutdown and cleanup on bridge unplug
7. Add notifier mechanism to let common code (the bridge-connector)
take actions on hotplug events
* drm: event-notifier: add mechanism to notify about hotplug events
* drm/bridge: notify about detached bridges
* drm/mipi-dsi: turn DRM_MIPI_DSI into a tristate
* drm/mipi-dsi: notify about DSI attach
8. Allow common code to know when the pipeline is complete
* drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline
* drm/bridge: panel: implement .is_tail
* drm/bridge: display-connector: implement .is_tail
* drm/bridge: samsung-dsim: implement .is_tail
* drm/bridge: ti-sn65dsi83: implement .is_tail
9. Allow probing incomplete pipelines
* drm/bridge: drm_bridge_attach(): don't fail on -EPROBE_DEFER
10. Implement bridge hotplug in bridge-connector, enable it in a driver
* drm/display: bridge-connector: handle bridge hotplug
* drm/mxsfb/lcdif: enable bridge hotplug
== Grand plan
This is part of the work to support hotplug of DRM bridges. The grand plan
was discussed in [0].
Here's the work breakdown (➜ marks the current series):
1. … add refcounting to DRM bridges struct drm_bridge,
based on devm_drm_bridge_alloc()
A. ✔ add new alloc API and refcounting (v6.16)
B. ✔ convert all bridge drivers to new API (v6.17)
C. ✔ kunit tests (v6.17)
D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
and warn on old allocation pattern (v6.17)
E. … add get/put on drm_bridge accessors
1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
2. ✔ drm_bridge_get_prev_bridge() (v6.18)
3. ✔ drm_bridge_get_next_bridge() (v6.19)
4. ✔ drm_for_each_bridge_in_chain() (v6.19)
5. ✔ drm_bridge_connector_init (v6.19)
6. ✔ protect encoder bridge chain with a mutex (v7.2)
7. ✔ of_drm_find_bridge
a. ✔ add of_drm_get_bridge() (v7.0),
convert basic direct users (v7.0-v7.1)
b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
d. ✔ convert direct of_drm_get_bridge() users, part 4 (v7.1-v7.2)
e. ✔ bridge-only drm_of_find_panel_or_bridge() users (v7.2)
8. drm_of_find_panel_or_bridge, *_of_get_bridge
9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
F. ✔ debugfs improvements
1. ✔ add top-level 'bridges' file (v6.16)
2. ✔ show refcount and list lingering bridges (v6.19)
2. … handle gracefully atomic updates during bridge removal
A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
B. … protect private_obj removal from list
C. ✔ Add drm_bridge_clear_and_put() (v7.1)
3. … DSI host-device driver interaction
4. ✔ removing the need for the "always-disconnected" connector
5. ✔ Migrate i.MX LCDIF driver to bridge-connector (v7.2)
6. ➜ DRM bridge hotplug
A. ➜ Bridge hotplug management in the DRM core
1. ✔ bridge-connector: attach encoder to the connector (v7.2)
2. ➜ drm bridge hotplug
B. Device tree description
[0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
== Dependencies
This series depends on:
* "drm/atomic: drm_atomic_private_obj_fini: protect private_obj removal
from list"
- https://lore.kernel.org/lkml/20260324-drm-bridge-atomic-vs-remove-private_obj-v3-1-64deefe84044@bootlin.com/
- Reason: avoid sporadic deadlock
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Luca Ceresoli (37):
drm/connector: split drmm_connector_hdmi_init() in 3 parts
drm/connector: add drm_connector_hdmi_dynamic_init()
drm/display: bridge-connector: rename variable for consistency
drm/display: bridge-connector: store the drm_device pointer
drm/display: bridge-connector: split code creating the connector to a subfunction
drm/display: bridge-connector: use a drm_bridge_connector internally, not a drm_connector
drm/display: bridge-connector: extract drm_bridge_connector_get_bridges()
drm/display: bridge-connector: return int from drm_bridge_connector_get_bridges()
drm/display: bridge-connector: extract drm_bridge_connector_init_hdmi_audio_cec()
drm/display: bridge-connector: return int from drm_bridge_connector_init_hdmi_audio_cec()
drm/display: bridge-connector: return int from drm_bridge_connector_add_connector()
drm/display: bridge-connector: hoist error management to common code
drm/display: bridge-connector: move drm_bridge_connector_put_bridges() definition eariler
drm/display: bridge-connector: add non-drmm variant of drm_bridge_connector_put_bridges()
drm/display: bridge-connector: allocate the connector dynamically
drm/display: bridge-connector: move per-connector fields to the dynamic connector
drm/display: bridge-connector: protect dynconn creation and destruction with a mutex
drm/bridge: samsung-dsim: remove the panel_bridge on host_detach
drm/bridge: samsung-dsim: move drm_bridge_add() call to probe
drm/bridge: samsung-dsim: attach: return -EPROBE_DEFER is next bridge not yet available
drm/bridge: initialize chain_node list head on allocation
drm/bridge: initialize chain_node list head on detach and attach errors
drm/encoder: add drm_encoder_cleanup_from()
drm/atomic: move drm_atomic_helper_disable_all() and drm_atomic_helper_shutdown() from drm_atomic_helper to drm_atomic
drm/bridge: shutdown and cleanup on bridge unplug
drm: event-notifier: add mechanism to notify about hotplug events
drm/bridge: notify about detached bridges
drm/mipi-dsi: turn DRM_MIPI_DSI into a tristate
drm/mipi-dsi: notify about DSI attach
drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline
drm/bridge: panel: implement .is_tail
drm/bridge: display-connector: implement .is_tail
drm/bridge: samsung-dsim: implement .is_tail
drm/bridge: ti-sn65dsi83: implement .is_tail
drm/bridge: drm_bridge_attach(): don't fail on -EPROBE_DEFER
drm/display: bridge-connector: handle bridge hotplug
drm/mxsfb/lcdif: enable bridge hotplug
drivers/gpu/drm/Kconfig | 7 +-
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/bridge/display-connector.c | 7 +
drivers/gpu/drm/bridge/panel.c | 8 +-
drivers/gpu/drm/bridge/samsung-dsim.c | 36 +-
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 7 +
drivers/gpu/drm/display/drm_bridge_connector.c | 835 +++++++++++++++++--------
drivers/gpu/drm/drm_atomic.c | 115 ++++
drivers/gpu/drm/drm_atomic_helper.c | 76 +--
drivers/gpu/drm/drm_bridge.c | 47 +-
drivers/gpu/drm/drm_connector.c | 155 +++--
drivers/gpu/drm/drm_encoder.c | 38 ++
drivers/gpu/drm/drm_event_notifier.c | 58 ++
drivers/gpu/drm/drm_mipi_dsi.c | 3 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 8 +-
include/drm/bridge/samsung-dsim.h | 2 +
include/drm/drm_atomic.h | 3 +
include/drm/drm_bridge.h | 19 +
include/drm/drm_bridge_connector.h | 2 +
include/drm/drm_connector.h | 9 +
include/drm/drm_encoder.h | 1 +
include/drm/drm_event_notifier.h | 36 ++
22 files changed, 1078 insertions(+), 396 deletions(-)
---
base-commit: 289b9a790d52a6865db3006f07922a9191faa54e
change-id: 20260515-drm-bridge-hotplug-46265d3a2f85
Best regards,
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-19 10:38 UTC (permalink / raw)
To: o.rempel, kernel, andi.shyti, Frank.Li, s.hauer, festevam,
carlos.song, haibo.chen
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
From: Carlos Song <carlos.song@nxp.com>
Mark the I2C adapter as suspended during system suspend to block further
transfers, and resume it on system resume. This prevents potential hangs
when the hardware is powered down but clients still attempt I2C transfers.
Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
drivers/i2c/busses/i2c-imx.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index a208fefd3c3b..3b19d4a424ca 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1913,6 +1913,34 @@ static int i2c_imx_runtime_resume(struct device *dev)
return ret;
}
+static int __maybe_unused i2c_imx_suspend_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_suspend(dev);
+ if (ret)
+ return ret;
+
+ i2c_mark_adapter_suspended(&i2c_imx->adapter);
+
+ return 0;
+}
+
+static int __maybe_unused i2c_imx_resume_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
+ i2c_mark_adapter_resumed(&i2c_imx->adapter);
+
+ return 0;
+}
+
static int i2c_imx_suspend(struct device *dev)
{
/*
@@ -1946,8 +1974,8 @@ static int i2c_imx_resume(struct device *dev)
}
static const struct dev_pm_ops i2c_imx_pm_ops = {
- NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+ NOIRQ_SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend_noirq,
+ i2c_imx_resume_noirq)
SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend, i2c_imx_resume)
RUNTIME_PM_OPS(i2c_imx_runtime_suspend, i2c_imx_runtime_resume, NULL)
};
--
2.43.0
^ permalink raw reply related
* [GIT PULL 2/2] Renesas DTS updates for v7.2
From: Geert Uytterhoeven @ 2026-05-19 10:35 UTC (permalink / raw)
To: soc, soc
Cc: Magnus Damm, linux-arm-kernel, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1779185457.git.geert+renesas@glider.be>
The following changes since commit 5d6919055dec134de3c40167a490f33c74c12581:
Linux 7.1-rc3 (2026-05-10 14:08:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dts-for-v7.2-tag1
for you to fetch changes up to 44f1ef06ceec55b7704c7d773d6136ca8b90f8b7:
ARM: dts: renesas: r8a73a4: Describe coresight on R-Mobile APE6 (2026-05-15 11:35:25 +0200)
----------------------------------------------------------------
Renesas DTS updates for v7.2
- Add GPU support for R-Car M3-W(+)-based ULCB and Salvator-X(S)
development boards,
- Add Ethernet, OPP table, interrupt, pin control, and watchdog
support for the RZ/G3L SoC and the RZ/G3L SMARC SoM board,
- Add Coresight support for the R-Mobile A1 and APE6 SoCs, and the
Armadillo-800 EVA and APE6EVM development boards,
- Miscellaneous fixes and improvements.
Note that this (1) is based on v7.1-rc3, as PowerVR GPU enablement has a
dependency on commit 26735dfdd8930d9e ("pmdomain: core: Fix detach
procedure for virtual devices in genpd"), and (2) includes:
- Renesas SoC fixes for v7.1, which are already present in
soc/for-next, but not yet in v7.1-rc4,
- DT binding definition updates for the R-Mobile A1 and APE6 SoCs,
which are shared by the clock subsystem and DT source files,
- DT binding definitions for the RZ/G3L SoC, which are shared by the
pin control subsystem and DT source files.
Thanks for pulling!
----------------------------------------------------------------
Biju Das (13):
dt-bindings: pinctrl: renesas,rzg2l-pinctrl: Document reset-names
dt-bindings: pinctrl: renesas: Document RZ/G3L SoC
arm64: dts: renesas: r9a08g046: Add GBETH nodes
arm64: dts: renesas: rzg3l-smarc-som: Enable eth0 (GBETH0) interface
arm64: dts: renesas: Add pinctrl reset-names for RZ/G2L and RZ/V2H family SoCs
arm64: dts: renesas: r9a08g046: Add OPP table
arm64: dts: renesas: r9a08g046: Add ICU node
arm64: dts: renesas: r9a08g046: Add pincontrol node
arm64: dts: renesas: r9a08g046l48-smarc: Add SCIF0 pincontrol
arm64: dts: renesas: rzg3l-smarc-som: Add pinctrl configuration for ETH0
arm64: dts: renesas: rzg3l-smarc-som: Enable eth1 (GBETH1) interface
arm64: dts: renesas: r9a08g046: Add wdt device node
arm64: dts: renesas: rzg3l-smarc-som: Enable watchdog
Geert Uytterhoeven (5):
arm64: dts: renesas: r8a78000: Fix SCIF brg_int clocks
Merge tag 'renesas-fixes-for-v7.1-tag1' into renesas-dts-for-v7.2
Merge tag 'renesas-r8a7740-dt-binding-defs-tag1' into renesas-dts-for-v7.2
Merge tag 'renesas-r9a08g046-dt-binding-defs-tag2' into renesas-dts-for-v7.2
Merge tag 'renesas-r8a73a4-dt-binding-defs-tag1' into renesas-dts-for-v7.2
Marek Vasut (24):
arm64: dts: renesas: draak/ebisu-panel: Fix missing cells and reg in DTO
arm64: dts: renesas: salvator-panel: Fix missing cells and reg in DTO
arm64: dts: renesas: rz-smarc-cru-csi-ov5645: Fix missing cells and reg in CSI2 subnode
arm64: dts: renesas: rz-smarc-du-adv7513-smarc: Fix missing cells and reg in DU subnode
ARM: dts: renesas: r8a7778: Add missing unit address to bus node
ARM: dts: renesas: r8a7779: Add missing unit address to bus node
ARM: dts: renesas: r8a7792: Add missing unit address to bus node
ARM: dts: renesas: r7s72100: Add missing unit address to bus node
ARM: dts: renesas: genmai: Drop superfluous cells
ARM: dts: renesas: rskrza1: Drop superfluous cells
dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile A1
arm64: dts: renesas: r8a77960-ulcb: Enable GPU support
arm64: dts: renesas: r8a77960-salvator-x: Enable GPU support
arm64: dts: renesas: r8a77960-salvator-xs: Enable GPU support
arm64: dts: renesas: r8a77961-ulcb: Enable GPU support
arm64: dts: renesas: r8a77961-salvator-xs: Enable GPU support
ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clocks
ARM: dts: renesas: r8a7740: Describe coresight
arm64: dts: renesas: gray-hawk-single: Fix AVB0 PHY node alignment
arm64: dts: renesas: ebisu: Sort sound node
arm64: dts: renesas: salvator-common: Sort sound node
dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile APE6
ARM: dts: renesas: r8a73a4: Add ZT/ZTR trace clock on R-Mobile APE6
ARM: dts: renesas: r8a73a4: Describe coresight on R-Mobile APE6
Tommaso Merciai (2):
arm64: dts: renesas: r9a09g057: Add #mux-state-cells to usb2{0,1}phyrst
arm64: dts: renesas: r9a09g056: Add #mux-state-cells to usb20phyrst
.../bindings/clock/renesas,cpg-clocks.yaml | 8 +-
.../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 35 ++
arch/arm/boot/dts/renesas/r7s72100-genmai.dts | 3 -
arch/arm/boot/dts/renesas/r7s72100-rskrza1.dts | 2 -
arch/arm/boot/dts/renesas/r7s72100.dtsi | 2 +-
arch/arm/boot/dts/renesas/r8a73a4.dtsi | 114 +++++-
arch/arm/boot/dts/renesas/r8a7740.dtsi | 116 +++++-
arch/arm/boot/dts/renesas/r8a7778.dtsi | 2 +-
arch/arm/boot/dts/renesas/r8a7779.dtsi | 2 +-
arch/arm/boot/dts/renesas/r8a7792.dtsi | 2 +-
.../dts/renesas/draak-ebisu-panel-aa104xd12.dtso | 5 +
arch/arm64/boot/dts/renesas/ebisu.dtsi | 34 +-
arch/arm64/boot/dts/renesas/gray-hawk-single.dtsi | 10 +-
.../arm64/boot/dts/renesas/r8a77960-salvator-x.dts | 4 +
.../boot/dts/renesas/r8a77960-salvator-xs.dts | 4 +
arch/arm64/boot/dts/renesas/r8a77960-ulcb.dts | 4 +
.../boot/dts/renesas/r8a77961-salvator-xs.dts | 4 +
arch/arm64/boot/dts/renesas/r8a77961-ulcb.dts | 4 +
arch/arm64/boot/dts/renesas/r8a78000.dtsi | 8 +-
arch/arm64/boot/dts/renesas/r9a07g043.dtsi | 1 +
arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 1 +
arch/arm64/boot/dts/renesas/r9a07g054.dtsi | 1 +
arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 1 +
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 402 ++++++++++++++++++++-
arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts | 13 +
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 1 +
arch/arm64/boot/dts/renesas/r9a09g056.dtsi | 2 +
arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 3 +
.../boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi | 5 +
.../boot/dts/renesas/rz-smarc-du-adv7513.dtsi | 5 +
arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi | 132 +++++++
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 26 +-
.../boot/dts/renesas/salvator-panel-aa104xd12.dtso | 5 +
include/dt-bindings/clock/r8a73a4-clock.h | 2 +
include/dt-bindings/clock/r8a7740-clock.h | 2 +
.../pinctrl/renesas,r9a08g046-pinctrl.h | 38 ++
36 files changed, 945 insertions(+), 58 deletions(-)
create mode 100644 include/dt-bindings/pinctrl/renesas,r9a08g046-pinctrl.h
^ permalink raw reply
* [GIT PULL 1/2] Renesas driver updates for v7.2
From: Geert Uytterhoeven @ 2026-05-19 10:35 UTC (permalink / raw)
To: soc, soc
Cc: Magnus Damm, linux-arm-kernel, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1779185457.git.geert+renesas@glider.be>
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v7.2-tag1
for you to fetch changes up to 17e48e7e5f18b45fd4a9411090148aae3b74f7f3:
soc: renesas: Convert to of_machine_get_match() (2026-05-11 09:56:17 +0200)
----------------------------------------------------------------
Renesas driver updates for v7.2
- Add Multifunctional Interface (MFIS) mailbox and product register
support for R-Car X5H,
- Miscellaneous fixes and improvements.
Note that this includes DT binding definitions for R-Car X5H, which are
shared by driver and DT source files.
Thanks for pulling!
----------------------------------------------------------------
Claudiu Beznea (5):
soc: renesas: r9a08g045-sysc: Move common code to a helper
soc: renesas: r9a08g046-sysc: Move common code to a helper
soc: renesas: r9a09g047-sys: Move common code to a helper
soc: renesas: r9a09g056-sys: Move common code to a helper
soc: renesas: r9a09g057-sys: Move common code to a helper
Geert Uytterhoeven (2):
Merge tag 'renesas-r8a78000-dt-binding-defs-tag1' into renesas-drivers-for-v7.2
soc: renesas: Convert to of_machine_get_match()
Wolfram Sang (3):
dt-bindings: soc: renesas: Document MFIS IP core
soc: renesas: Add Renesas R-Car MFIS driver
soc: renesas: Add R-Car X5H PRR support
.../soc/renesas/renesas,r8a78000-mfis.yaml | 187 +++++++++++
drivers/soc/renesas/Kconfig | 9 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r9a08g045-sysc.c | 33 +-
drivers/soc/renesas/r9a08g046-sysc.c | 31 +-
drivers/soc/renesas/r9a09g047-sys.c | 34 +-
drivers/soc/renesas/r9a09g056-sys.c | 33 +-
drivers/soc/renesas/r9a09g057-sys.c | 44 +--
drivers/soc/renesas/rcar-mfis.c | 344 +++++++++++++++++++++
drivers/soc/renesas/renesas-soc.c | 10 +-
include/dt-bindings/soc/renesas,r8a78000-mfis.h | 28 ++
11 files changed, 644 insertions(+), 110 deletions(-)
create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
create mode 100644 drivers/soc/renesas/rcar-mfis.c
create mode 100644 include/dt-bindings/soc/renesas,r8a78000-mfis.h
^ permalink raw reply
* [GIT PULL 0/2] Renesas SoC updates for v7.2
From: Geert Uytterhoeven @ 2026-05-19 10:35 UTC (permalink / raw)
To: soc, soc
Cc: Magnus Damm, linux-arm-kernel, linux-renesas-soc,
Geert Uytterhoeven
Hi SoC folks,
This is my first pull request for the inclusion of Renesas SoC updates
for v7.2.
It consists of 2 parts:
[GIT PULL 1/2] Renesas driver updates for v7.2
- Add Multifunctional Interface (MFIS) mailbox and product register
support for R-Car X5H,
- Miscellaneous fixes and improvements.
[GIT PULL 2/2] Renesas DTS updates for v7.2
- Add GPU support for R-Car M3-W(+)-based ULCB and Salvator-X(S)
development boards,
- Add Ethernet, OPP table, interrupt, pin control, and watchdog
support for the RZ/G3L SoC and the RZ/G3L SMARC SoM board,
- Add Coresight support for the R-Mobile A1 and APE6 SoCs, and the
Armadillo-800 EVA and APE6EVM development boards,
- Miscellaneous fixes and improvements.
Note that the first PR includes DT binding definitions for R-Car X5H,
which are shared by driver and DT source files.
Note that the second PR (1) is based on v7.1-rc3, as PowerVR GPU
enablement has a dependency on commit 26735dfdd8930d9e ("pmdomain: core:
Fix detach procedure for virtual devices in genpd"), and (2) includes:
- Renesas SoC fixes for v7.1, which are already present in
soc/for-next, but not yet in v7.1-rc4,
- DT binding definition updates for the R-Mobile A1 and APE6 SoCs,
which are shared by the clock subsystem and DT source files,
- DT binding definitions for the RZ/G3L SoC, which are shared by the
pin control subsystem and DT source files.
Thanks for pulling!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH v2 1/2] i2c: imx: Don't recover bus when arbitration lost
From: Carlos Song (OSS) @ 2026-05-19 10:29 UTC (permalink / raw)
To: Dan Scally
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Gao Pan, Fugang Duan, Wolfram Sang,
Oleksij Rempel, Pengutronix Kernel Team
In-Reply-To: <aa1a6931-1a98-4f72-b8fc-ae05df28f931@ideasonboard.com>
> -----Original Message-----
> From: Dan Scally <dan.scally@ideasonboard.com>
> Sent: Tuesday, May 19, 2026 4:42 PM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>
> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; Andi Shyti <andi.shyti@kernel.org>; Frank
> Li <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Fabio
> Estevam <festevam@gmail.com>; Gao Pan <b54642@freescale.com>; Fugang
> Duan <B38611@freescale.com>; Wolfram Sang <wsa@kernel.org>
> Subject: Re: [PATCH v2 1/2] i2c: imx: Don't recover bus when arbitration lost
>
> [You don't often get email from dan.scally@ideasonboard.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello Oleksij / all
>
> On 24/04/2026 13:36, Daniel Scally wrote:
> > In i2c_imx_xfer_common(), the driver attempts bus recovery whenever
> > i2c_imx_start() fails. One of the failure modes for i2c_imx_start() is
> > an arbitration-lost signal which results when a second I2C master on
> > the bus tries to control the bus simultaneously, which is a normal and
> > expected behaviour.
> >
> > Bus recovery is not the right response for this case. Add a check for
> > the -EAGAIN return code to avoid running the bus recovery.
> >
> > Fixes: 1c4b6c3bcf30d ("i2c: imx: implement bus recovery")
> > Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
> > ---
>
> I raised this patch after we had issues with one of the i2c controllers on imx8mp.
> In that case, the bus had multiple masters that were causing the SoC's i2c
> controller to lose arbitration. The result was that the framework attempted to
> run i2c_generic_scl_recovery() and regularly hit the "SCL is stuck low, exit
> recovery" message [1] because the bus was busy rather than stuck.
>
> I'm now experiencing a different issue with the imx8mp in which a different
> controller - which isn't on a multiple-masters bus - starts transacting fine early in
> boot, but then seems to get stuck - any attempt to start a transaction by either
> a driver or i2ctransfer results in the IAL bit in I2C_I2SR being set and so the
> driver reports that it's lost arbitration [2]. In this case, the bus recovery is
> needed to fix the problem, and so this commit hurts things rather than helps
> them. This problem isn't consistent - I get it on maybe 10% of boots.
>
Hi Dan,
This is the RM shows:
Arbitration lost. Set by hardware in the following circumstances (IAL must be cleared by software by
writing a "0" to it at the start of the interrupt service routine):
* I2Cn_SDA input samples low when the master drives high during an address or data-transmit cycle.
* I2Cn_SDA input samples low when the master drives high during the acknowledge bit of a datareceive
cycle.
For the above two cases, the bit is set at the falling edge of the ninth I2Cn_SCL clock during the ACK
cycle.
* A Start cycle is attempted when the bus is busy.
* A Repeated Start cycle is requested in Slave mode.
* A Stop condition is detected when the master did not request it.
NOTE: Software cannot set the bit.
0 No arbitration lost.
1 Arbitration is lost.
From my understanding:
The IAL (Arbitration Lost) bit is set not only when true arbitration is lost, but also in several other conditions:
- SDA is sampled low when the master drives it high (during address/data or ACK phase)
- A START is attempted while the bus is busy
- A STOP condition is detected unexpectedly
- A repeated START occurs in slave mode
So in practice, IAL can be asserted not only by real arbitration loss, but also when the controller detects abnormal bus conditions.
Since your system is single-master, this is unlikely to be a true arbitration scenario. Instead, it is more likely caused by signal integrity or timing-related issues, such as:
- weak pull-up / slow rising edges
- noise or glitches on SDA
- timing violations from the slave device
- others
As a workaround, you can enable the 'single-master' property to disable arbitration checks in single-master systems, for example:
&i2c1 {
clock-frequency = <400000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
single-master;
status = "okay";
};
Hope it will help some.
Carlos
^ permalink raw reply
* Re: [PATCH v14 37/44] arm64: RMI: Prevent Device mappings for Realms
From: Aneesh Kumar K.V @ 2026-05-19 10:25 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Steven Price, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-38-steven.price@arm.com>
Steven Price <steven.price@arm.com> writes:
> Physical device assignment is not yet supported. RMM v2.0 does add the
> relevant APIs, but device assignment is a big topic so will be handled
> in a future patch series. For now prevent device mappings when the guest
> is a realm.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes from v6:
> * Fix the check in user_mem_abort() to prevent all pages that are not
> guest_memfd() from being mapped into the protected half of the IPA.
> Changes from v5:
> * Also prevent accesses in user_mem_abort()
> ---
> arch/arm64/kvm/mmu.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 776ffe56d17e..7678226ffd38 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1230,6 +1230,10 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> if (is_protected_kvm_enabled())
> return -EPERM;
>
> + /* We don't support mapping special pages into a Realm */
> + if (kvm_is_realm(kvm))
> + return -EPERM;
> +
> size += offset_in_page(guest_ipa);
> guest_ipa &= PAGE_MASK;
>
The commit message suggests that this will need to be updated to support
Device Assignment, but that is not true. IIUC, this is only used by
GICv2?. Can we update the commit message?
-aneesh
^ permalink raw reply
* Re: [PATCH] arm64: cpucaps: Keep entries sorted
From: Marc Zyngier @ 2026-05-19 10:22 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel, Catalin Marinas, Mark Rutland
In-Reply-To: <20260519092243.7278-1-will@kernel.org>
On Tue, 19 May 2026 10:22:42 +0100,
Will Deacon <will@kernel.org> wrote:
>
> The cpucaps list is supposed to be sorted, even though the awk script
> which processes it doesn't really care. Since this isn't enforced or
> relied upon and because the alphabet is hard, the list has gradually
> developed an ordering of its own.
>
> Re-sort the file.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Reported-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>
> Marc pointed out that HAS_BBML2_NOABORT was in the wrong place but, on
> closer inspection, there are a bunch of misplaced entries here. I
> honestly don't like the churn of re-sorting it, so an alternative is
> to live with it and remove the comment at the top asking people to keep
> it sorted it. Any preferences?
I'm not sold on the requirement for keeping this sorted, TBH. The
commit message says "to minimise conflicts", which I can understand as
it avoids people adding entries at the end all the time, but it is
obvious that we (especially myself) can't manage to do that.
If we want to keep this sorted for $reasons, let's actively enforce it
in the generation script:
diff --git a/arch/arm64/tools/gen-cpucaps.awk b/arch/arm64/tools/gen-cpucaps.awk
index 2f4f61a0af17e..2e06768ff432e 100755
--- a/arch/arm64/tools/gen-cpucaps.awk
+++ b/arch/arm64/tools/gen-cpucaps.awk
@@ -20,10 +20,14 @@ BEGIN {
print ""
print "/* Generated file - do not edit */"
cap_num = 0
+ previous = ""
print ""
}
/^[vA-Z0-9_]+$/ {
+ if (cap_num > 0 && previous > $0)
+ fatal("unsorted cap " $0)
+ previous = $0
printf("#define ARM64_%-40s\t%d\n", $0, cap_num++)
next
}
although that results in a different sorting order (my awk-foo is limited).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH v4 3/5] firmware: raspberrypi: register nvmem driver
From: Gregor Herburger @ 2026-05-19 10:21 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, linux-hardening
In-Reply-To: <20260519111442-f1e6d418-9a92-4934-8a9c-c5f7827f853e@linutronix.de>
On Tue, May 19, 2026 at 11:15:59AM +0200, Thomas Weißschuh wrote:
> On Fri, May 08, 2026 at 04:42:46PM +0200, Gregor Herburger wrote:
> > The Raspberry Pi firmware exposes two regions with otp registers. The
> > first region called "customer otp" is available on all Raspberry Pi
> > models. The second is only available on the Raspberry Pi 5 (bcm2712).
>
> (...)
>
> > @@ -327,12 +371,25 @@ static void rpi_firmware_remove(struct platform_device *pdev)
> > rpi_hwmon = NULL;
> > platform_device_unregister(rpi_clk);
> > rpi_clk = NULL;
> > + platform_device_unregister(rpi_otp_customer);
> > + rpi_otp_customer = NULL;
> > + if (rpi_otp_private)
>
> This check looks unnecessary.
Looking at platform_device_unregister again it does not do anything when
rpi_otp_private is NULL so i will drop the if.
>
> > + platform_device_unregister(rpi_otp_private);
> > +
> > + rpi_otp_private = NULL;
> >
> > rpi_firmware_put(fw);
> > }
Regards
Gregor
^ permalink raw reply
* Re: [PATCH v4 2/5] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-05-19 10:20 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, linux-hardening
In-Reply-To: <20260519110041-2d8d92c2-d265-43d1-848f-bf9231a106c8@linutronix.de>
On Tue, May 19, 2026 at 11:14:28AM +0200, Thomas Weißschuh wrote:
> On Fri, May 08, 2026 at 04:42:45PM +0200, Gregor Herburger wrote:
> > +config NVMEM_RASPBERRYPI_OTP
> > + tristate "Raspberry Pi OTP support"
> > + depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
>
> The '&& !RASPBERRYPI_FIRMWARE' clause looks weird, is it really necessary?
Yes it does looks weird but I think it is necessary. Without this it would be
possible to build RASPBERRYPI_FIRMWARE=m and NVMEM_RASPBERRYPI_OTP=y which
results in linker errors.
>
> > + help
> > + This driver provides access to the Raspberry Pi OTP memory via the
> > + nvmem subsystem. The driver supports the customer OTP as well as the
> > + device specific private key OTP (BCM2712 only).
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called raspberrypi-otp.
>
> While we are here: The empty line here is now missing.
Oh. Thanks will add it again.
>
> > +++ b/drivers/nvmem/raspberrypi-otp.c
> > @@ -0,0 +1,130 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +#include <linux/overflow.h>
>
> This looks unused.
>
> Instead maybe add linux/types.h, linux/align.h
>
Thanks will drop it and add the suggested headers.
> > +struct rpi_otp_priv {
> > + struct rpi_firmware *fw;
> > + struct device *dev;
>
> This looks unused.
>
Thansk will remove.
> > +static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
> > +{
> > + struct rpi_otp_priv *priv = context;
> > + struct rpi_otp_header *fwbuf;
> > + u32 count;
> > + int ret;
> > +
> > + if (!IS_ALIGNED(offset, 4) || !IS_ALIGNED(bytes, 4))
> > + return -EINVAL;
>
> Isn't this already enforced by the nvmem core?
Only for sysfs access through bin_attr_nvmem_read/bin_attr_nvmem_write. But
there is an in-kernel API nvmem_device_read/nvmem_device_write which does not
have alignment checks. So I added the check to be more defensive here.
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + data = dev_get_platdata(dev);
> > + if (!data)
> > + return -ENODEV;
>
> I would do this before the devm_kzalloc().
Yes will change.
> > +module_platform_driver(raspberry_otp_driver);
> > +
> > +MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
> > +MODULE_DESCRIPTION("Raspberry Pi OTP driver");
> > +MODULE_LICENSE("GPL");
> > +MODULE_ALIAS("platform:raspberrypi-otp");
>
> Instead of the manual module alias here and the implicit matching of the
> platform driver this should use an explicit matching table:
>
> static const struct platform_device_id foo_id[] = {
> { "raspberrypi-otp" },
> {}
> };
> MODULE_DEVICE_TABLE(platform, foo_id);
>
> static struct platform_driver raspberry_otp_driver = {
> ...
> .id_table = foo_id,
> };
> module_platform_driver(raspberry_otp_driver);
>
Sounds right will change it.
Regards
Gregor
^ permalink raw reply
* Re: [PATCH v14 27/44] arm64: RMI: Set RIPAS of initial memslots
From: Suzuki K Poulose @ 2026-05-19 10:13 UTC (permalink / raw)
To: Aneesh Kumar K.V, Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Emi Kisanuki, Vishal Annapurve, WeiLin.Chang,
Lorenzo.Pieralisi2
In-Reply-To: <yq5av7cjsonr.fsf@kernel.org>
On 19/05/2026 11:02, Aneesh Kumar K.V wrote:
> Steven Price <steven.price@arm.com> writes:
>
>> The memory which the realm guest accesses must be set to RIPAS_RAM.
>> Iterate over the memslots and set all gmem memslots to RIPAS_RAM.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>
> ...
>
>> +static int set_ripas_of_protected_regions(struct kvm *kvm)
>> +{
>> + struct kvm_memslots *slots;
>> + struct kvm_memory_slot *memslot;
>> + int idx, bkt;
>> + int ret = 0;
>> +
>> + idx = srcu_read_lock(&kvm->srcu);
>> +
>> + slots = kvm_memslots(kvm);
>> + kvm_for_each_memslot(memslot, bkt, slots) {
>> + if (!kvm_slot_has_gmem(memslot))
>> + continue;
>> +
>> + ret = realm_init_ipa_state(kvm, memslot->base_gfn,
>> + memslot->npages);
>> + if (ret)
>> + break;
>> + }
>> + srcu_read_unlock(&kvm->srcu, idx);
>> +
>> + return ret;
>> +}
>> +
>> int kvm_arm_rmi_populate(struct kvm *kvm,
>> struct kvm_arm_rmi_populate *args)
>> {
>> @@ -890,6 +922,10 @@ int kvm_activate_realm(struct kvm *kvm)
>> return ret;
>> }
>>
>> + ret = set_ripas_of_protected_regions(kvm);
>> + if (ret)
>> + return ret;
>> +
>> ret = rmi_realm_activate(virt_to_phys(realm->rd));
>> if (ret)
>> return -ENXIO;
>
> relam guest already does.
> for_each_mem_range(i, &start, &end) {
> if (rsi_set_memory_range_protected_safe(start, end)) {
> panic("Failed to set memory range to protected: %pa-%pa",
> &start, &end);
> }
> }
>
> if so why is host required to do this ?
Ideally this should be a call from the VMM (i.e., user). Irrespective of
what the guest does (which the host has no knowledge about), the VMM/
user is better aware of what to do for a given guest. We have done this
implicitly in the KVM as a start, to keep the initial implementation
simple. This could be moved out to the VMM as UABI, if there is
sufficient demand for it.
TL,DR: This should be a host/deployer decision, not the Guest. There
may other guest OS, which do not do RIPAS_RAM early enough.
Suzuki
^ permalink raw reply
* [PATCH v2] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Kohei Enju @ 2026-05-19 10:12 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Sami Mujawar, Gavin Shan, Steven Price, Suzuki K Poulose,
linux-arm-kernel, linux-kernel, Kohei Enju
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.
Note that while migrate_disable() would pin the task to the current CPU,
this path should not block CPU hotplug events. Therefore, we snapshot
the current CPU ID and accept that smp_call_function_single() may fail
if the CPU goes offline.
[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
[...]
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
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 | 9 ++++++++-
1 file changed, 8 insertions(+), 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..b463bf35bf30 100644
--- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
+++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
@@ -107,8 +107,15 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
* instead of simply calling get_cpu() because of the need to
* allocate outblob based on the returned value from the 'init'
* call and that cannot be done in an atomic context.
+ *
+ * While migrate_disable() would pin the task to the current CPU,
+ * this path should not block CPU hotplug events. Therefore, we
+ * snapshot the current CPU ID and accept that
+ * smp_call_function_single() may fail if the CPU goes offline.
+ * Any resulting error is propagated to user-space, which is
+ * expected to handle it.
*/
- cpu = smp_processor_id();
+ cpu = raw_smp_processor_id();
info.challenge = desc->inblob;
info.challenge_size = desc->inblob_len;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 2/2] regulator: Use named initializers for arrays of i2c_device_data
From: Laurent Pinchart @ 2026-05-19 10:07 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Liam Girdwood, Mark Brown, Michael Hennerich, Support Opensource,
Ivaylo Ivanov, Claudiu Beznea, Andrei Simion, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Woodrow Douglass,
Jagan Teki, Icenowy Zheng, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <9a8bfc7286221873ef02eeba0727eeaeb9e504e8.1779184320.git.u.kleine-koenig@baylibre.com>
On Tue, May 19, 2026 at 11:57:51AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> The mentioned robustness is relevant for a planned change to struct
> i2c_device_id that replaces .driver_data by an anonymous union.
>
> While touching all these arrays, unify usage of whitespace and commas.
>
> This patch doesn't modify the compiled arrays, only their representation
> in source form benefits. The former was confirmed with x86 and arm64
> builds.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/regulator/88pg86x.c | 4 +--
> drivers/regulator/ad5398.c | 4 +--
> drivers/regulator/da9121-regulator.c | 20 +++++++--------
> drivers/regulator/da9210-regulator.c | 4 +--
> drivers/regulator/da9211-regulator.c | 18 +++++++-------
> drivers/regulator/fan53880.c | 4 +--
> drivers/regulator/isl9305.c | 4 +--
> drivers/regulator/lp3971.c | 2 +-
> drivers/regulator/lp3972.c | 2 +-
> drivers/regulator/lp872x.c | 34 +++++++++++++-------------
> drivers/regulator/lp8755.c | 4 +--
> drivers/regulator/ltc3589.c | 6 ++---
> drivers/regulator/ltc3676.c | 2 +-
> drivers/regulator/max1586.c | 2 +-
> drivers/regulator/max20086-regulator.c | 8 +++---
> drivers/regulator/max20411-regulator.c | 2 +-
> drivers/regulator/max77503-regulator.c | 2 +-
> drivers/regulator/max77675-regulator.c | 2 +-
> drivers/regulator/max77826-regulator.c | 2 +-
> drivers/regulator/max77838-regulator.c | 2 +-
> drivers/regulator/max77857-regulator.c | 8 +++---
> drivers/regulator/max8649.c | 2 +-
> drivers/regulator/max8893.c | 2 +-
> drivers/regulator/max8952.c | 2 +-
> drivers/regulator/mcp16502.c | 2 +-
> drivers/regulator/mp5416.c | 6 ++---
> drivers/regulator/mp8859.c | 4 +--
> drivers/regulator/mp886x.c | 6 ++---
> drivers/regulator/mpq7920.c | 4 +--
> drivers/regulator/mt6311-regulator.c | 4 +--
> drivers/regulator/pf530x-regulator.c | 6 ++---
> drivers/regulator/pf8x00-regulator.c | 8 +++---
> drivers/regulator/pv88060-regulator.c | 4 +--
> drivers/regulator/pv88080-regulator.c | 8 +++---
> drivers/regulator/pv88090-regulator.c | 4 +--
> drivers/regulator/slg51000-regulator.c | 4 +--
> drivers/regulator/sy8106a-regulator.c | 2 +-
> drivers/regulator/sy8824x.c | 8 +++---
> drivers/regulator/sy8827n.c | 4 +--
> drivers/regulator/tps6286x-regulator.c | 10 ++++----
> drivers/regulator/tps6287x-regulator.c | 10 ++++----
> 41 files changed, 118 insertions(+), 118 deletions(-)
[snip]
> diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
> index 942f37082cb1..779df653338a 100644
> --- a/drivers/regulator/lp872x.c
> +++ b/drivers/regulator/lp872x.c
> @@ -796,24 +796,24 @@ static const struct regmap_config lp872x_regmap_config = {
> #define LP872X_VALID_OPMODE (REGULATOR_MODE_FAST | REGULATOR_MODE_NORMAL)
>
> static struct of_regulator_match lp8720_matches[] = {
This is unrelated to the commit message that only mentions
i2c_device_id.
With this chunk dropped,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> - { .name = "ldo1", .driver_data = (void *)LP8720_ID_LDO1, },
> - { .name = "ldo2", .driver_data = (void *)LP8720_ID_LDO2, },
> - { .name = "ldo3", .driver_data = (void *)LP8720_ID_LDO3, },
> - { .name = "ldo4", .driver_data = (void *)LP8720_ID_LDO4, },
> - { .name = "ldo5", .driver_data = (void *)LP8720_ID_LDO5, },
> - { .name = "buck", .driver_data = (void *)LP8720_ID_BUCK, },
> + { .name = "ldo1", .driver_data = (void *)LP8720_ID_LDO1 },
> + { .name = "ldo2", .driver_data = (void *)LP8720_ID_LDO2 },
> + { .name = "ldo3", .driver_data = (void *)LP8720_ID_LDO3 },
> + { .name = "ldo4", .driver_data = (void *)LP8720_ID_LDO4 },
> + { .name = "ldo5", .driver_data = (void *)LP8720_ID_LDO5 },
> + { .name = "buck", .driver_data = (void *)LP8720_ID_BUCK },
> };
>
> static struct of_regulator_match lp8725_matches[] = {
> - { .name = "ldo1", .driver_data = (void *)LP8725_ID_LDO1, },
> - { .name = "ldo2", .driver_data = (void *)LP8725_ID_LDO2, },
> - { .name = "ldo3", .driver_data = (void *)LP8725_ID_LDO3, },
> - { .name = "ldo4", .driver_data = (void *)LP8725_ID_LDO4, },
> - { .name = "ldo5", .driver_data = (void *)LP8725_ID_LDO5, },
> - { .name = "lilo1", .driver_data = (void *)LP8725_ID_LILO1, },
> - { .name = "lilo2", .driver_data = (void *)LP8725_ID_LILO2, },
> - { .name = "buck1", .driver_data = (void *)LP8725_ID_BUCK1, },
> - { .name = "buck2", .driver_data = (void *)LP8725_ID_BUCK2, },
> + { .name = "ldo1", .driver_data = (void *)LP8725_ID_LDO1 },
> + { .name = "ldo2", .driver_data = (void *)LP8725_ID_LDO2 },
> + { .name = "ldo3", .driver_data = (void *)LP8725_ID_LDO3 },
> + { .name = "ldo4", .driver_data = (void *)LP8725_ID_LDO4 },
> + { .name = "ldo5", .driver_data = (void *)LP8725_ID_LDO5 },
> + { .name = "lilo1", .driver_data = (void *)LP8725_ID_LILO1 },
> + { .name = "lilo2", .driver_data = (void *)LP8725_ID_LILO2 },
> + { .name = "buck1", .driver_data = (void *)LP8725_ID_BUCK1 },
> + { .name = "buck2", .driver_data = (void *)LP8725_ID_BUCK2 },
> };
>
> static struct lp872x_platform_data
> @@ -935,8 +935,8 @@ static const struct of_device_id lp872x_dt_ids[] __maybe_unused = {
> MODULE_DEVICE_TABLE(of, lp872x_dt_ids);
>
> static const struct i2c_device_id lp872x_ids[] = {
> - {"lp8720", LP8720},
> - {"lp8725", LP8725},
> + { .name = "lp8720", .driver_data = LP8720 },
> + { .name = "lp8725", .driver_data = LP8725 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, lp872x_ids);
[snip]
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 4/4] firmware: arm_scmi: Validate Powercap domains before state access
From: Cristian Marussi @ 2026-05-19 10:04 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Cristian Marussi, arm-scmi, linux-arm-kernel
In-Reply-To: <20260517-scmi_fixes-v1-4-d86daec4defd@kernel.org>
On Sun, May 17, 2026 at 08:02:43PM +0100, Sudeep Holla wrote:
> Powercap protocol v2 keeps local enable and last-cap state per
> domain. Some public operations indexed that state before checking that
> the supplied domain id was valid, and cap_enable_get() updated it even
> when cap_get() failed.
>
> Validate the domain before touching the per-domain state and only
> refresh cached enable state after a successful cap_get().
>
Hi,
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> ---
> drivers/firmware/arm_scmi/powercap.c | 25 ++++++++++++++++++-------
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/powercap.c b/drivers/firmware/arm_scmi/powercap.c
> index ab9733f4458b..eb5c35cad026 100644
> --- a/drivers/firmware/arm_scmi/powercap.c
> +++ b/drivers/firmware/arm_scmi/powercap.c
> @@ -453,10 +453,14 @@ static int scmi_powercap_cap_set(const struct scmi_protocol_handle *ph,
> return -EINVAL;
>
> /* Just log the last set request if acting on a disabled domain */
> - if (PROTOCOL_REV_MAJOR(ph->version) >= 0x2 &&
> - !pi->states[domain_id].enabled) {
> - pi->states[domain_id].last_pcap = power_cap;
> - return 0;
> + if (PROTOCOL_REV_MAJOR(ph->version) >= 0x2) {
> + if (!scmi_powercap_dom_info_get(ph, domain_id))
> + return -EINVAL;
> +
> + if (!pi->states[domain_id].enabled) {
> + pi->states[domain_id].last_pcap = power_cap;
> + return 0;
> + }
> }
Yes, definitely better.
>
> return __scmi_powercap_cap_set(ph, pi, domain_id,
> @@ -637,6 +641,9 @@ static int scmi_powercap_cap_enable_set(const struct scmi_protocol_handle *ph,
> if (PROTOCOL_REV_MAJOR(ph->version) < 0x2)
> return -EINVAL;
>
> + if (!scmi_powercap_dom_info_get(ph, domain_id))
> + return -EINVAL;
> +
> if (enable == pi->states[domain_id].enabled)
> return 0;
>
> @@ -678,16 +685,20 @@ static int scmi_powercap_cap_enable_get(const struct scmi_protocol_handle *ph,
> if (PROTOCOL_REV_MAJOR(ph->version) < 0x2)
> return 0;
>
> + if (!scmi_powercap_dom_info_get(ph, domain_id))
> + return -EINVAL;
> +
Ok.
> /*
> * Report always real platform state; platform could have ignored
> * a previous disable request. Default true on any error.
> */
> ret = scmi_powercap_cap_get(ph, domain_id, &power_cap);
> - if (!ret)
> + if (!ret) {
> *enable = !!power_cap;
>
> - /* Update internal state with current real platform state */
> - pi->states[domain_id].enabled = *enable;
> + /* Update internal state with current real platform state */
> + pi->states[domain_id].enabled = *enable;
> + }
Mmm, this changes the logic as stated in the above comments...now the
problem is recalling WHY I adopted this logic :<
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v14 27/44] arm64: RMI: Set RIPAS of initial memslots
From: Aneesh Kumar K.V @ 2026-05-19 10:02 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Steven Price, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-28-steven.price@arm.com>
Steven Price <steven.price@arm.com> writes:
> The memory which the realm guest accesses must be set to RIPAS_RAM.
> Iterate over the memslots and set all gmem memslots to RIPAS_RAM.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
...
> +static int set_ripas_of_protected_regions(struct kvm *kvm)
> +{
> + struct kvm_memslots *slots;
> + struct kvm_memory_slot *memslot;
> + int idx, bkt;
> + int ret = 0;
> +
> + idx = srcu_read_lock(&kvm->srcu);
> +
> + slots = kvm_memslots(kvm);
> + kvm_for_each_memslot(memslot, bkt, slots) {
> + if (!kvm_slot_has_gmem(memslot))
> + continue;
> +
> + ret = realm_init_ipa_state(kvm, memslot->base_gfn,
> + memslot->npages);
> + if (ret)
> + break;
> + }
> + srcu_read_unlock(&kvm->srcu, idx);
> +
> + return ret;
> +}
> +
> int kvm_arm_rmi_populate(struct kvm *kvm,
> struct kvm_arm_rmi_populate *args)
> {
> @@ -890,6 +922,10 @@ int kvm_activate_realm(struct kvm *kvm)
> return ret;
> }
>
> + ret = set_ripas_of_protected_regions(kvm);
> + if (ret)
> + return ret;
> +
> ret = rmi_realm_activate(virt_to_phys(realm->rd));
> if (ret)
> return -ENXIO;
relam guest already does.
for_each_mem_range(i, &start, &end) {
if (rsi_set_memory_range_protected_safe(start, end)) {
panic("Failed to set memory range to protected: %pa-%pa",
&start, &end);
}
}
if so why is host required to do this ?
-aneesh
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: display: imx: Add television encoder (TVE) for imx53
From: Krzysztof Kozlowski @ 2026-05-19 9:59 UTC (permalink / raw)
To: Frank Li
Cc: Philipp Zabel, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:DRM DRIVERS FOR FREESCALE IMX 5/6,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20260512223137.1190096-1-Frank.Li@nxp.com>
On Tue, May 12, 2026 at 06:31:35PM -0400, Frank Li wrote:
> + ddc-i2c-bus:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to the I2C bus used for DDC (Display Data Channel) communication
> + to read EDID information from the connected display.
> +
> + dac-supply:
> + description:
> + Regulator supply for the TVE DAC (Digital-to-Analog Converter).
> +
> + fsl,tve-mode:
This should be a required property, based on current driver code.
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + TVE output mode selection.
> + enum:
> + - ntsc
> + - pal
> + - vga
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 09/10] dt-bindings: firmware: add arm,ras-cper
From: Ahmed Tiba @ 2026-05-19 9:57 UTC (permalink / raw)
To: Krzysztof Kozlowski, rafael, bp, saket.dumbre, will, xueshuai,
mchehab, krzk+dt, dave, conor+dt, vishal.l.verma, jic23, corbet,
guohanjun, dave.jiang, catalin.marinas, lenb, tony.luck, skhan,
djbw, alison.schofield, ira.weiny, robh
Cc: devicetree, linux-acpi, linux-doc, Dmitry.Lamerov, linux-cxl,
Michael.Zhao2, acpica-devel, linux-kernel, linux-arm-kernel,
linux-edac
In-Reply-To: <d12b5738-ca14-40aa-930f-eddf3199818d@kernel.org>
On 19/05/2026 10:22, Krzysztof Kozlowski wrote:
> On 19/05/2026 11:02, Ahmed Tiba wrote:
>> On 19/05/2026 08:04, Krzysztof Kozlowski wrote:
>>> On 18/05/2026 13:57, Ahmed Tiba wrote:
>>>> Describe the DeviceTree node that exposes the Arm firmware-first
>>>> CPER provider and hook the file into MAINTAINERS so the
>>>> binding has an owner.
>>>>
>>>> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
>>>
>>> Please implement previous comments.
>>
>> Could you please clarify which previous DT comments you still see
>> as unaddressed?
>>
>> My understanding was that I had addressed the earlier points on the YAML
>> description formatting, the `memory-region` description text, and the
>> example. If I missed a specific item beyond the one below, please point
>> me to it.
>
> You do not need other nodes for your device in the example. I asked why
> this is needed for the example, but there was no answer.
Understood. I wanted the example to show the full binding context,
including how the `memory-region` phandles point to the reserved memory,
but I see your point.
I will remove the `reserved-memory` node from the example and simplify
it to only the `arm,ras-cper` device node.
Best regards,
Ahmed
^ permalink raw reply
* [PATCH v2 2/2] regulator: Use named initializers for arrays of i2c_device_data
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-19 9:57 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Michael Hennerich, Support Opensource, Laurent Pinchart,
Ivaylo Ivanov, Claudiu Beznea, Andrei Simion, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Woodrow Douglass,
Jagan Teki, Icenowy Zheng, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <cover.1779184320.git.u.kleine-koenig@baylibre.com>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
While touching all these arrays, unify usage of whitespace and commas.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/regulator/88pg86x.c | 4 +--
drivers/regulator/ad5398.c | 4 +--
drivers/regulator/da9121-regulator.c | 20 +++++++--------
drivers/regulator/da9210-regulator.c | 4 +--
drivers/regulator/da9211-regulator.c | 18 +++++++-------
drivers/regulator/fan53880.c | 4 +--
drivers/regulator/isl9305.c | 4 +--
drivers/regulator/lp3971.c | 2 +-
drivers/regulator/lp3972.c | 2 +-
drivers/regulator/lp872x.c | 34 +++++++++++++-------------
drivers/regulator/lp8755.c | 4 +--
drivers/regulator/ltc3589.c | 6 ++---
drivers/regulator/ltc3676.c | 2 +-
drivers/regulator/max1586.c | 2 +-
drivers/regulator/max20086-regulator.c | 8 +++---
drivers/regulator/max20411-regulator.c | 2 +-
drivers/regulator/max77503-regulator.c | 2 +-
drivers/regulator/max77675-regulator.c | 2 +-
drivers/regulator/max77826-regulator.c | 2 +-
drivers/regulator/max77838-regulator.c | 2 +-
drivers/regulator/max77857-regulator.c | 8 +++---
drivers/regulator/max8649.c | 2 +-
drivers/regulator/max8893.c | 2 +-
drivers/regulator/max8952.c | 2 +-
drivers/regulator/mcp16502.c | 2 +-
drivers/regulator/mp5416.c | 6 ++---
drivers/regulator/mp8859.c | 4 +--
drivers/regulator/mp886x.c | 6 ++---
drivers/regulator/mpq7920.c | 4 +--
drivers/regulator/mt6311-regulator.c | 4 +--
drivers/regulator/pf530x-regulator.c | 6 ++---
drivers/regulator/pf8x00-regulator.c | 8 +++---
drivers/regulator/pv88060-regulator.c | 4 +--
drivers/regulator/pv88080-regulator.c | 8 +++---
drivers/regulator/pv88090-regulator.c | 4 +--
drivers/regulator/slg51000-regulator.c | 4 +--
drivers/regulator/sy8106a-regulator.c | 2 +-
drivers/regulator/sy8824x.c | 8 +++---
drivers/regulator/sy8827n.c | 4 +--
drivers/regulator/tps6286x-regulator.c | 10 ++++----
drivers/regulator/tps6287x-regulator.c | 10 ++++----
41 files changed, 118 insertions(+), 118 deletions(-)
diff --git a/drivers/regulator/88pg86x.c b/drivers/regulator/88pg86x.c
index e6598e74ec94..8c25a1db412f 100644
--- a/drivers/regulator/88pg86x.c
+++ b/drivers/regulator/88pg86x.c
@@ -92,8 +92,8 @@ static const struct of_device_id __maybe_unused pg86x_dt_ids[] = {
MODULE_DEVICE_TABLE(of, pg86x_dt_ids);
static const struct i2c_device_id pg86x_i2c_id[] = {
- { "88pg867", },
- { "88pg868", },
+ { .name = "88pg867" },
+ { .name = "88pg868" },
{ }
};
MODULE_DEVICE_TABLE(i2c, pg86x_i2c_id);
diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
index eb2a666a45cb..0123ca8157a8 100644
--- a/drivers/regulator/ad5398.c
+++ b/drivers/regulator/ad5398.c
@@ -207,8 +207,8 @@ struct ad5398_current_data_format {
static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
static const struct i2c_device_id ad5398_id[] = {
- { "ad5398", (kernel_ulong_t)&df_10_4_120 },
- { "ad5821", (kernel_ulong_t)&df_10_4_120 },
+ { .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
+ { .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ad5398_id);
diff --git a/drivers/regulator/da9121-regulator.c b/drivers/regulator/da9121-regulator.c
index 2b150bb4d471..8155f0974f7d 100644
--- a/drivers/regulator/da9121-regulator.c
+++ b/drivers/regulator/da9121-regulator.c
@@ -1195,16 +1195,16 @@ static void da9121_i2c_remove(struct i2c_client *i2c)
}
static const struct i2c_device_id da9121_i2c_id[] = {
- {"da9121", DA9121_TYPE_DA9121_DA9130},
- {"da9130", DA9121_TYPE_DA9121_DA9130},
- {"da9217", DA9121_TYPE_DA9217},
- {"da9122", DA9121_TYPE_DA9122_DA9131},
- {"da9131", DA9121_TYPE_DA9122_DA9131},
- {"da9220", DA9121_TYPE_DA9220_DA9132},
- {"da9132", DA9121_TYPE_DA9220_DA9132},
- {"da9141", DA9121_TYPE_DA9141},
- {"da9142", DA9121_TYPE_DA9142},
- {},
+ { .name = "da9121", .driver_data = DA9121_TYPE_DA9121_DA9130 },
+ { .name = "da9130", .driver_data = DA9121_TYPE_DA9121_DA9130 },
+ { .name = "da9217", .driver_data = DA9121_TYPE_DA9217 },
+ { .name = "da9122", .driver_data = DA9121_TYPE_DA9122_DA9131 },
+ { .name = "da9131", .driver_data = DA9121_TYPE_DA9122_DA9131 },
+ { .name = "da9220", .driver_data = DA9121_TYPE_DA9220_DA9132 },
+ { .name = "da9132", .driver_data = DA9121_TYPE_DA9220_DA9132 },
+ { .name = "da9141", .driver_data = DA9121_TYPE_DA9141 },
+ { .name = "da9142", .driver_data = DA9121_TYPE_DA9142 },
+ { }
};
MODULE_DEVICE_TABLE(i2c, da9121_i2c_id);
diff --git a/drivers/regulator/da9210-regulator.c b/drivers/regulator/da9210-regulator.c
index 39ade0dba40f..9154e32bd745 100644
--- a/drivers/regulator/da9210-regulator.c
+++ b/drivers/regulator/da9210-regulator.c
@@ -202,8 +202,8 @@ static int da9210_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id da9210_i2c_id[] = {
- { "da9210" },
- {}
+ { .name = "da9210" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, da9210_i2c_id);
diff --git a/drivers/regulator/da9211-regulator.c b/drivers/regulator/da9211-regulator.c
index d4f14d7ea8cf..9cf713755636 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -522,15 +522,15 @@ static int da9211_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id da9211_i2c_id[] = {
- {"da9211", DA9211},
- {"da9212", DA9212},
- {"da9213", DA9213},
- {"da9223", DA9223},
- {"da9214", DA9214},
- {"da9224", DA9224},
- {"da9215", DA9215},
- {"da9225", DA9225},
- {},
+ { .name = "da9211", .driver_data = DA9211 },
+ { .name = "da9212", .driver_data = DA9212 },
+ { .name = "da9213", .driver_data = DA9213 },
+ { .name = "da9223", .driver_data = DA9223 },
+ { .name = "da9214", .driver_data = DA9214 },
+ { .name = "da9224", .driver_data = DA9224 },
+ { .name = "da9215", .driver_data = DA9215 },
+ { .name = "da9225", .driver_data = DA9225 },
+ { }
};
MODULE_DEVICE_TABLE(i2c, da9211_i2c_id);
diff --git a/drivers/regulator/fan53880.c b/drivers/regulator/fan53880.c
index 6cb5656845f9..79ba705ec324 100644
--- a/drivers/regulator/fan53880.c
+++ b/drivers/regulator/fan53880.c
@@ -164,8 +164,8 @@ static const struct of_device_id fan53880_dt_ids[] = {
MODULE_DEVICE_TABLE(of, fan53880_dt_ids);
static const struct i2c_device_id fan53880_i2c_id[] = {
- { "fan53880", },
- {}
+ { .name = "fan53880" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, fan53880_i2c_id);
diff --git a/drivers/regulator/isl9305.c b/drivers/regulator/isl9305.c
index 5a234f25e6bb..ec6bd6bb9721 100644
--- a/drivers/regulator/isl9305.c
+++ b/drivers/regulator/isl9305.c
@@ -186,8 +186,8 @@ MODULE_DEVICE_TABLE(of, isl9305_dt_ids);
#endif
static const struct i2c_device_id isl9305_i2c_id[] = {
- { "isl9305", },
- { "isl9305h", },
+ { .name = "isl9305" },
+ { .name = "isl9305h" },
{ }
};
MODULE_DEVICE_TABLE(i2c, isl9305_i2c_id);
diff --git a/drivers/regulator/lp3971.c b/drivers/regulator/lp3971.c
index d4dab86fe385..6f830ae1bb61 100644
--- a/drivers/regulator/lp3971.c
+++ b/drivers/regulator/lp3971.c
@@ -439,7 +439,7 @@ static int lp3971_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id lp3971_i2c_id[] = {
- { "lp3971" },
+ { .name = "lp3971" },
{ }
};
MODULE_DEVICE_TABLE(i2c, lp3971_i2c_id);
diff --git a/drivers/regulator/lp3972.c b/drivers/regulator/lp3972.c
index 1b918fb72134..235c640ba57f 100644
--- a/drivers/regulator/lp3972.c
+++ b/drivers/regulator/lp3972.c
@@ -537,7 +537,7 @@ static int lp3972_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id lp3972_i2c_id[] = {
- { "lp3972" },
+ { .name = "lp3972" },
{ }
};
MODULE_DEVICE_TABLE(i2c, lp3972_i2c_id);
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 942f37082cb1..779df653338a 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -796,24 +796,24 @@ static const struct regmap_config lp872x_regmap_config = {
#define LP872X_VALID_OPMODE (REGULATOR_MODE_FAST | REGULATOR_MODE_NORMAL)
static struct of_regulator_match lp8720_matches[] = {
- { .name = "ldo1", .driver_data = (void *)LP8720_ID_LDO1, },
- { .name = "ldo2", .driver_data = (void *)LP8720_ID_LDO2, },
- { .name = "ldo3", .driver_data = (void *)LP8720_ID_LDO3, },
- { .name = "ldo4", .driver_data = (void *)LP8720_ID_LDO4, },
- { .name = "ldo5", .driver_data = (void *)LP8720_ID_LDO5, },
- { .name = "buck", .driver_data = (void *)LP8720_ID_BUCK, },
+ { .name = "ldo1", .driver_data = (void *)LP8720_ID_LDO1 },
+ { .name = "ldo2", .driver_data = (void *)LP8720_ID_LDO2 },
+ { .name = "ldo3", .driver_data = (void *)LP8720_ID_LDO3 },
+ { .name = "ldo4", .driver_data = (void *)LP8720_ID_LDO4 },
+ { .name = "ldo5", .driver_data = (void *)LP8720_ID_LDO5 },
+ { .name = "buck", .driver_data = (void *)LP8720_ID_BUCK },
};
static struct of_regulator_match lp8725_matches[] = {
- { .name = "ldo1", .driver_data = (void *)LP8725_ID_LDO1, },
- { .name = "ldo2", .driver_data = (void *)LP8725_ID_LDO2, },
- { .name = "ldo3", .driver_data = (void *)LP8725_ID_LDO3, },
- { .name = "ldo4", .driver_data = (void *)LP8725_ID_LDO4, },
- { .name = "ldo5", .driver_data = (void *)LP8725_ID_LDO5, },
- { .name = "lilo1", .driver_data = (void *)LP8725_ID_LILO1, },
- { .name = "lilo2", .driver_data = (void *)LP8725_ID_LILO2, },
- { .name = "buck1", .driver_data = (void *)LP8725_ID_BUCK1, },
- { .name = "buck2", .driver_data = (void *)LP8725_ID_BUCK2, },
+ { .name = "ldo1", .driver_data = (void *)LP8725_ID_LDO1 },
+ { .name = "ldo2", .driver_data = (void *)LP8725_ID_LDO2 },
+ { .name = "ldo3", .driver_data = (void *)LP8725_ID_LDO3 },
+ { .name = "ldo4", .driver_data = (void *)LP8725_ID_LDO4 },
+ { .name = "ldo5", .driver_data = (void *)LP8725_ID_LDO5 },
+ { .name = "lilo1", .driver_data = (void *)LP8725_ID_LILO1 },
+ { .name = "lilo2", .driver_data = (void *)LP8725_ID_LILO2 },
+ { .name = "buck1", .driver_data = (void *)LP8725_ID_BUCK1 },
+ { .name = "buck2", .driver_data = (void *)LP8725_ID_BUCK2 },
};
static struct lp872x_platform_data
@@ -935,8 +935,8 @@ static const struct of_device_id lp872x_dt_ids[] __maybe_unused = {
MODULE_DEVICE_TABLE(of, lp872x_dt_ids);
static const struct i2c_device_id lp872x_ids[] = {
- {"lp8720", LP8720},
- {"lp8725", LP8725},
+ { .name = "lp8720", .driver_data = LP8720 },
+ { .name = "lp8725", .driver_data = LP8725 },
{ }
};
MODULE_DEVICE_TABLE(i2c, lp872x_ids);
diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c
index 5509bee49bda..632320ba1800 100644
--- a/drivers/regulator/lp8755.c
+++ b/drivers/regulator/lp8755.c
@@ -430,8 +430,8 @@ static void lp8755_remove(struct i2c_client *client)
}
static const struct i2c_device_id lp8755_id[] = {
- { LP8755_NAME },
- {}
+ { .name = LP8755_NAME },
+ { }
};
MODULE_DEVICE_TABLE(i2c, lp8755_id);
diff --git a/drivers/regulator/ltc3589.c b/drivers/regulator/ltc3589.c
index 3f70c2225dba..8bae5d8aeaf4 100644
--- a/drivers/regulator/ltc3589.c
+++ b/drivers/regulator/ltc3589.c
@@ -445,9 +445,9 @@ static const struct ltc3589_info ltc3589_12_info = {
};
static const struct i2c_device_id ltc3589_i2c_id[] = {
- { "ltc3589", (kernel_ulong_t)<c3589_info },
- { "ltc3589-1", (kernel_ulong_t)<c3589_12_info },
- { "ltc3589-2", (kernel_ulong_t)<c3589_12_info },
+ { .name = "ltc3589", .driver_data = (kernel_ulong_t)<c3589_info },
+ { .name = "ltc3589-1", .driver_data = (kernel_ulong_t)<c3589_12_info },
+ { .name = "ltc3589-2", .driver_data = (kernel_ulong_t)<c3589_12_info },
{ }
};
MODULE_DEVICE_TABLE(i2c, ltc3589_i2c_id);
diff --git a/drivers/regulator/ltc3676.c b/drivers/regulator/ltc3676.c
index 73d511eb1c1d..597d20a200d7 100644
--- a/drivers/regulator/ltc3676.c
+++ b/drivers/regulator/ltc3676.c
@@ -357,7 +357,7 @@ static int ltc3676_regulator_probe(struct i2c_client *client)
}
static const struct i2c_device_id ltc3676_i2c_id[] = {
- { "ltc3676" },
+ { .name = "ltc3676" },
{ }
};
MODULE_DEVICE_TABLE(i2c, ltc3676_i2c_id);
diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 4242fbb7b147..e5cbc09c2d39 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -276,7 +276,7 @@ static int max1586_pmic_probe(struct i2c_client *client)
}
static const struct i2c_device_id max1586_id[] = {
- { "max1586" },
+ { .name = "max1586" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max1586_id);
diff --git a/drivers/regulator/max20086-regulator.c b/drivers/regulator/max20086-regulator.c
index fcdd2d0317a5..92594b2915f3 100644
--- a/drivers/regulator/max20086-regulator.c
+++ b/drivers/regulator/max20086-regulator.c
@@ -301,10 +301,10 @@ static const struct max20086_chip_info max20089_chip_info = {
};
static const struct i2c_device_id max20086_i2c_id[] = {
- { "max20086", (kernel_ulong_t)&max20086_chip_info },
- { "max20087", (kernel_ulong_t)&max20087_chip_info },
- { "max20088", (kernel_ulong_t)&max20088_chip_info },
- { "max20089", (kernel_ulong_t)&max20089_chip_info },
+ { .name = "max20086", .driver_data = (kernel_ulong_t)&max20086_chip_info },
+ { .name = "max20087", .driver_data = (kernel_ulong_t)&max20087_chip_info },
+ { .name = "max20088", .driver_data = (kernel_ulong_t)&max20088_chip_info },
+ { .name = "max20089", .driver_data = (kernel_ulong_t)&max20089_chip_info },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, max20086_i2c_id);
diff --git a/drivers/regulator/max20411-regulator.c b/drivers/regulator/max20411-regulator.c
index 6c0ebb970e90..ac7a9aa014aa 100644
--- a/drivers/regulator/max20411-regulator.c
+++ b/drivers/regulator/max20411-regulator.c
@@ -145,7 +145,7 @@ static const struct of_device_id of_max20411_match_tbl[] = {
MODULE_DEVICE_TABLE(of, of_max20411_match_tbl);
static const struct i2c_device_id max20411_id[] = {
- { "max20411" },
+ { .name = "max20411" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max20411_id);
diff --git a/drivers/regulator/max77503-regulator.c b/drivers/regulator/max77503-regulator.c
index c7c94e868fc1..1cae846f96d0 100644
--- a/drivers/regulator/max77503-regulator.c
+++ b/drivers/regulator/max77503-regulator.c
@@ -107,7 +107,7 @@ static const struct of_device_id of_max77503_match_tbl[] = {
MODULE_DEVICE_TABLE(of, of_max77503_match_tbl);
static const struct i2c_device_id max77503_regulator_id[] = {
- {"max77503"},
+ { .name = "max77503" },
{ }
};
diff --git a/drivers/regulator/max77675-regulator.c b/drivers/regulator/max77675-regulator.c
index 57350526afd7..ebea08ddf4b8 100644
--- a/drivers/regulator/max77675-regulator.c
+++ b/drivers/regulator/max77675-regulator.c
@@ -1029,7 +1029,7 @@ static int max77675_regulator_probe(struct i2c_client *client)
}
static const struct i2c_device_id max77675_i2c_id[] = {
- { "max77675" },
+ { .name = "max77675" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max77675_i2c_id);
diff --git a/drivers/regulator/max77826-regulator.c b/drivers/regulator/max77826-regulator.c
index 310bc8ee7af8..8b60a9fcab44 100644
--- a/drivers/regulator/max77826-regulator.c
+++ b/drivers/regulator/max77826-regulator.c
@@ -278,7 +278,7 @@ static const struct of_device_id __maybe_unused max77826_of_match[] = {
MODULE_DEVICE_TABLE(of, max77826_of_match);
static const struct i2c_device_id max77826_id[] = {
- { "max77826-regulator" },
+ { .name = "max77826-regulator" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, max77826_id);
diff --git a/drivers/regulator/max77838-regulator.c b/drivers/regulator/max77838-regulator.c
index 9faddbfd25fd..765756fdcf6e 100644
--- a/drivers/regulator/max77838-regulator.c
+++ b/drivers/regulator/max77838-regulator.c
@@ -200,7 +200,7 @@ static const struct of_device_id __maybe_unused max77838_of_match[] = {
MODULE_DEVICE_TABLE(of, max77838_of_match);
static const struct i2c_device_id max77838_id[] = {
- { "max77838-regulator" },
+ { .name = "max77838-regulator" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, max77838_id);
diff --git a/drivers/regulator/max77857-regulator.c b/drivers/regulator/max77857-regulator.c
index 1216cc3a6f72..f1410f845653 100644
--- a/drivers/regulator/max77857-regulator.c
+++ b/drivers/regulator/max77857-regulator.c
@@ -428,10 +428,10 @@ static int max77857_probe(struct i2c_client *client)
}
static const struct i2c_device_id max77857_id[] = {
- { "max77831", ID_MAX77831 },
- { "max77857", ID_MAX77857 },
- { "max77859", ID_MAX77859 },
- { "max77859a", ID_MAX77859A },
+ { .name = "max77831", .driver_data = ID_MAX77831 },
+ { .name = "max77857", .driver_data = ID_MAX77857 },
+ { .name = "max77859", .driver_data = ID_MAX77859 },
+ { .name = "max77859a", .driver_data = ID_MAX77859A },
{ }
};
MODULE_DEVICE_TABLE(i2c, max77857_id);
diff --git a/drivers/regulator/max8649.c b/drivers/regulator/max8649.c
index f57c588bcf28..2d17405242e7 100644
--- a/drivers/regulator/max8649.c
+++ b/drivers/regulator/max8649.c
@@ -240,7 +240,7 @@ static int max8649_regulator_probe(struct i2c_client *client)
}
static const struct i2c_device_id max8649_id[] = {
- { "max8649" },
+ { .name = "max8649" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max8649_id);
diff --git a/drivers/regulator/max8893.c b/drivers/regulator/max8893.c
index 5a90633d8536..7a0e44a16d49 100644
--- a/drivers/regulator/max8893.c
+++ b/drivers/regulator/max8893.c
@@ -162,7 +162,7 @@ MODULE_DEVICE_TABLE(of, max8893_dt_match);
#endif
static const struct i2c_device_id max8893_ids[] = {
- { "max8893" },
+ { .name = "max8893" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max8893_ids);
diff --git a/drivers/regulator/max8952.c b/drivers/regulator/max8952.c
index 1f94315bfb02..f8b91a5701f3 100644
--- a/drivers/regulator/max8952.c
+++ b/drivers/regulator/max8952.c
@@ -307,7 +307,7 @@ static int max8952_pmic_probe(struct i2c_client *client)
}
static const struct i2c_device_id max8952_ids[] = {
- { "max8952" },
+ { .name = "max8952" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max8952_ids);
diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
index b34ae0bbba6f..89fd79d446f7 100644
--- a/drivers/regulator/mcp16502.c
+++ b/drivers/regulator/mcp16502.c
@@ -578,7 +578,7 @@ static const struct dev_pm_ops mcp16502_pm_ops = {
};
#endif
static const struct i2c_device_id mcp16502_i2c_id[] = {
- { "mcp16502" },
+ { .name = "mcp16502" },
{ }
};
MODULE_DEVICE_TABLE(i2c, mcp16502_i2c_id);
diff --git a/drivers/regulator/mp5416.c b/drivers/regulator/mp5416.c
index e6794190cb68..2948635b1b9f 100644
--- a/drivers/regulator/mp5416.c
+++ b/drivers/regulator/mp5416.c
@@ -228,9 +228,9 @@ static const struct of_device_id mp5416_of_match[] = {
MODULE_DEVICE_TABLE(of, mp5416_of_match);
static const struct i2c_device_id mp5416_id[] = {
- { "mp5416", (kernel_ulong_t)&mp5416_regulators_desc },
- { "mp5496", (kernel_ulong_t)&mp5496_regulators_desc },
- {}
+ { .name = "mp5416", .driver_data = (kernel_ulong_t)&mp5416_regulators_desc },
+ { .name = "mp5496", .driver_data = (kernel_ulong_t)&mp5496_regulators_desc },
+ { }
};
MODULE_DEVICE_TABLE(i2c, mp5416_id);
diff --git a/drivers/regulator/mp8859.c b/drivers/regulator/mp8859.c
index ab105ffd6a2e..9a708e826d93 100644
--- a/drivers/regulator/mp8859.c
+++ b/drivers/regulator/mp8859.c
@@ -386,8 +386,8 @@ static const struct of_device_id mp8859_dt_id[] __maybe_unused = {
MODULE_DEVICE_TABLE(of, mp8859_dt_id);
static const struct i2c_device_id mp8859_i2c_id[] = {
- { "mp8859", },
- { },
+ { .name = "mp8859" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, mp8859_i2c_id);
diff --git a/drivers/regulator/mp886x.c b/drivers/regulator/mp886x.c
index 9ad16b04c913..e0b62bc02a1e 100644
--- a/drivers/regulator/mp886x.c
+++ b/drivers/regulator/mp886x.c
@@ -348,9 +348,9 @@ static const struct of_device_id mp886x_dt_ids[] = {
MODULE_DEVICE_TABLE(of, mp886x_dt_ids);
static const struct i2c_device_id mp886x_id[] = {
- { "mp8867", (kernel_ulong_t)&mp8867_ci },
- { "mp8869", (kernel_ulong_t)&mp8869_ci },
- { },
+ { .name = "mp8867", .driver_data = (kernel_ulong_t)&mp8867_ci },
+ { .name = "mp8869", .driver_data = (kernel_ulong_t)&mp8869_ci },
+ { }
};
MODULE_DEVICE_TABLE(i2c, mp886x_id);
diff --git a/drivers/regulator/mpq7920.c b/drivers/regulator/mpq7920.c
index a670e09891e7..0cbc17deb1d1 100644
--- a/drivers/regulator/mpq7920.c
+++ b/drivers/regulator/mpq7920.c
@@ -309,8 +309,8 @@ static const struct of_device_id mpq7920_of_match[] = {
MODULE_DEVICE_TABLE(of, mpq7920_of_match);
static const struct i2c_device_id mpq7920_id[] = {
- { "mpq7920", },
- { },
+ { .name = "mpq7920" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, mpq7920_id);
diff --git a/drivers/regulator/mt6311-regulator.c b/drivers/regulator/mt6311-regulator.c
index 2ebc1c0b5e6f..1d457d1fdf23 100644
--- a/drivers/regulator/mt6311-regulator.c
+++ b/drivers/regulator/mt6311-regulator.c
@@ -133,8 +133,8 @@ static int mt6311_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id mt6311_i2c_id[] = {
- { "mt6311" },
- {}
+ { .name = "mt6311" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, mt6311_i2c_id);
diff --git a/drivers/regulator/pf530x-regulator.c b/drivers/regulator/pf530x-regulator.c
index ef3d5bb784cd..8ad1cbbd7a8c 100644
--- a/drivers/regulator/pf530x-regulator.c
+++ b/drivers/regulator/pf530x-regulator.c
@@ -353,9 +353,9 @@ static const struct of_device_id pf530x_dt_ids[] = {
MODULE_DEVICE_TABLE(of, pf530x_dt_ids);
static const struct i2c_device_id pf530x_i2c_id[] = {
- { "pf5300" },
- { "pf5301" },
- { "pf5302" },
+ { .name = "pf5300" },
+ { .name = "pf5301" },
+ { .name = "pf5302" },
{ }
};
MODULE_DEVICE_TABLE(i2c, pf530x_i2c_id);
diff --git a/drivers/regulator/pf8x00-regulator.c b/drivers/regulator/pf8x00-regulator.c
index ea3611de42b4..c938b4632ef1 100644
--- a/drivers/regulator/pf8x00-regulator.c
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -596,10 +596,10 @@ static const struct of_device_id pf8x00_dt_ids[] = {
MODULE_DEVICE_TABLE(of, pf8x00_dt_ids);
static const struct i2c_device_id pf8x00_i2c_id[] = {
- { "pf8100" },
- { "pf8121a" },
- { "pf8200" },
- {}
+ { .name = "pf8100" },
+ { .name = "pf8121a" },
+ { .name = "pf8200" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, pf8x00_i2c_id);
diff --git a/drivers/regulator/pv88060-regulator.c b/drivers/regulator/pv88060-regulator.c
index ae1c4b9daaa1..375d9e759c47 100644
--- a/drivers/regulator/pv88060-regulator.c
+++ b/drivers/regulator/pv88060-regulator.c
@@ -360,8 +360,8 @@ static int pv88060_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id pv88060_i2c_id[] = {
- { "pv88060" },
- {}
+ { .name = "pv88060" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, pv88060_i2c_id);
diff --git a/drivers/regulator/pv88080-regulator.c b/drivers/regulator/pv88080-regulator.c
index 9fe539a34786..3dc48d059791 100644
--- a/drivers/regulator/pv88080-regulator.c
+++ b/drivers/regulator/pv88080-regulator.c
@@ -523,10 +523,10 @@ static const struct of_device_id pv88080_dt_ids[] = {
MODULE_DEVICE_TABLE(of, pv88080_dt_ids);
static const struct i2c_device_id pv88080_i2c_id[] = {
- { "pv88080", (kernel_ulong_t)&pv88080_aa_regs },
- { "pv88080-aa", (kernel_ulong_t)&pv88080_aa_regs },
- { "pv88080-ba", (kernel_ulong_t)&pv88080_ba_regs },
- {}
+ { .name = "pv88080", .driver_data = (kernel_ulong_t)&pv88080_aa_regs },
+ { .name = "pv88080-aa", .driver_data = (kernel_ulong_t)&pv88080_aa_regs },
+ { .name = "pv88080-ba", .driver_data = (kernel_ulong_t)&pv88080_ba_regs },
+ { }
};
MODULE_DEVICE_TABLE(i2c, pv88080_i2c_id);
diff --git a/drivers/regulator/pv88090-regulator.c b/drivers/regulator/pv88090-regulator.c
index 3c48757bbbda..ca5eeb5dfe62 100644
--- a/drivers/regulator/pv88090-regulator.c
+++ b/drivers/regulator/pv88090-regulator.c
@@ -381,8 +381,8 @@ static int pv88090_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id pv88090_i2c_id[] = {
- { "pv88090" },
- {}
+ { .name = "pv88090" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, pv88090_i2c_id);
diff --git a/drivers/regulator/slg51000-regulator.c b/drivers/regulator/slg51000-regulator.c
index 3bbd4a29e6d3..d682764cdbf8 100644
--- a/drivers/regulator/slg51000-regulator.c
+++ b/drivers/regulator/slg51000-regulator.c
@@ -497,8 +497,8 @@ static int slg51000_i2c_probe(struct i2c_client *client)
}
static const struct i2c_device_id slg51000_i2c_id[] = {
- { "slg51000" },
- {}
+ { .name = "slg51000" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, slg51000_i2c_id);
diff --git a/drivers/regulator/sy8106a-regulator.c b/drivers/regulator/sy8106a-regulator.c
index d79a4cc25a0d..b2b835c60262 100644
--- a/drivers/regulator/sy8106a-regulator.c
+++ b/drivers/regulator/sy8106a-regulator.c
@@ -130,7 +130,7 @@ static const struct of_device_id sy8106a_i2c_of_match[] = {
MODULE_DEVICE_TABLE(of, sy8106a_i2c_of_match);
static const struct i2c_device_id sy8106a_i2c_id[] = {
- { "sy8106a" },
+ { .name = "sy8106a" },
{ }
};
MODULE_DEVICE_TABLE(i2c, sy8106a_i2c_id);
diff --git a/drivers/regulator/sy8824x.c b/drivers/regulator/sy8824x.c
index 5bec84db25f1..3f07e7da90cb 100644
--- a/drivers/regulator/sy8824x.c
+++ b/drivers/regulator/sy8824x.c
@@ -213,10 +213,10 @@ static const struct of_device_id sy8824_dt_ids[] = {
MODULE_DEVICE_TABLE(of, sy8824_dt_ids);
static const struct i2c_device_id sy8824_id[] = {
- { "sy8824c", (kernel_ulong_t)&sy8824c_cfg },
- { "sy8824e", (kernel_ulong_t)&sy8824e_cfg },
- { "sy20276", (kernel_ulong_t)&sy20276_cfg },
- { "sy20278", (kernel_ulong_t)&sy20278_cfg },
+ { .name = "sy8824c", .driver_data = (kernel_ulong_t)&sy8824c_cfg },
+ { .name = "sy8824e", .driver_data = (kernel_ulong_t)&sy8824e_cfg },
+ { .name = "sy20276", .driver_data = (kernel_ulong_t)&sy20276_cfg },
+ { .name = "sy20278", .driver_data = (kernel_ulong_t)&sy20278_cfg },
{ }
};
MODULE_DEVICE_TABLE(i2c, sy8824_id);
diff --git a/drivers/regulator/sy8827n.c b/drivers/regulator/sy8827n.c
index 0b811514782f..a1cac8cc3d96 100644
--- a/drivers/regulator/sy8827n.c
+++ b/drivers/regulator/sy8827n.c
@@ -180,8 +180,8 @@ static const struct of_device_id sy8827n_dt_ids[] = {
MODULE_DEVICE_TABLE(of, sy8827n_dt_ids);
static const struct i2c_device_id sy8827n_id[] = {
- { "sy8827n", },
- { },
+ { .name = "sy8827n" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, sy8827n_id);
diff --git a/drivers/regulator/tps6286x-regulator.c b/drivers/regulator/tps6286x-regulator.c
index e29aab06bf79..1ab53bee9f6e 100644
--- a/drivers/regulator/tps6286x-regulator.c
+++ b/drivers/regulator/tps6286x-regulator.c
@@ -145,11 +145,11 @@ static int tps6286x_i2c_probe(struct i2c_client *i2c)
}
static const struct i2c_device_id tps6286x_i2c_id[] = {
- { "tps62864" },
- { "tps62866" },
- { "tps62868" },
- { "tps62869" },
- {}
+ { .name = "tps62864" },
+ { .name = "tps62866" },
+ { .name = "tps62868" },
+ { .name = "tps62869" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, tps6286x_i2c_id);
diff --git a/drivers/regulator/tps6287x-regulator.c b/drivers/regulator/tps6287x-regulator.c
index 7b7d3ae39206..c0bc4a6192c4 100644
--- a/drivers/regulator/tps6287x-regulator.c
+++ b/drivers/regulator/tps6287x-regulator.c
@@ -229,11 +229,11 @@ static const struct of_device_id tps6287x_dt_ids[] = {
MODULE_DEVICE_TABLE(of, tps6287x_dt_ids);
static const struct i2c_device_id tps6287x_i2c_id[] = {
- { "tps62870" },
- { "tps62871" },
- { "tps62872" },
- { "tps62873" },
- {}
+ { .name = "tps62870" },
+ { .name = "tps62871" },
+ { .name = "tps62872" },
+ { .name = "tps62873" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, tps6287x_i2c_id);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/2] regulator: Rework i2c_device_id initialisation
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-19 9:57 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Laurent Pinchart, Woodrow Douglass, linux-kernel,
Michael Hennerich, Support Opensource, Ivaylo Ivanov,
Claudiu Beznea, Andrei Simion, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Jagan Teki, Icenowy Zheng,
linux-arm-kernel, linux-mediatek
Hello,
Laurent pointed out one driver in my v1
(https://lore.kernel.org/linux-kernel/20260515103150.164887-2-u.kleine-koenig@baylibre.com)
that doesn't actually make use of its .driver_data. I found a second
while adapting the patch set. So this v2 consists of a first patch that
drops these driver data assigments and a second to convert to named
initializers which is mostly the patch sent before.
It might be too conservative, but I didn't apply Laurent's conditional
Reviewed-by tag as my change is a bit different than anticipated.
Best regards
Uwe
Uwe Kleine-König (The Capable Hub) (2):
regulator: Drop unused i2c driver data
regulator: Use named initializers for arrays of i2c_device_data
drivers/regulator/88pg86x.c | 4 +--
drivers/regulator/ad5398.c | 4 +--
drivers/regulator/da9121-regulator.c | 20 +++++++--------
drivers/regulator/da9210-regulator.c | 4 +--
drivers/regulator/da9211-regulator.c | 18 +++++++-------
drivers/regulator/fan53880.c | 4 +--
drivers/regulator/isl9305.c | 4 +--
drivers/regulator/lp3971.c | 2 +-
drivers/regulator/lp3972.c | 2 +-
drivers/regulator/lp872x.c | 34 +++++++++++++-------------
drivers/regulator/lp8755.c | 4 +--
drivers/regulator/ltc3589.c | 6 ++---
drivers/regulator/ltc3676.c | 2 +-
drivers/regulator/max1586.c | 2 +-
drivers/regulator/max20086-regulator.c | 8 +++---
drivers/regulator/max20411-regulator.c | 2 +-
drivers/regulator/max77503-regulator.c | 2 +-
drivers/regulator/max77675-regulator.c | 2 +-
drivers/regulator/max77826-regulator.c | 2 +-
drivers/regulator/max77838-regulator.c | 2 +-
drivers/regulator/max77857-regulator.c | 8 +++---
drivers/regulator/max8649.c | 2 +-
drivers/regulator/max8893.c | 2 +-
drivers/regulator/max8952.c | 2 +-
drivers/regulator/mcp16502.c | 2 +-
drivers/regulator/mp5416.c | 6 ++---
drivers/regulator/mp8859.c | 4 +--
drivers/regulator/mp886x.c | 6 ++---
drivers/regulator/mpq7920.c | 4 +--
drivers/regulator/mt6311-regulator.c | 4 +--
drivers/regulator/pf530x-regulator.c | 8 +++---
drivers/regulator/pf8x00-regulator.c | 8 +++---
drivers/regulator/pv88060-regulator.c | 4 +--
drivers/regulator/pv88080-regulator.c | 8 +++---
drivers/regulator/pv88090-regulator.c | 4 +--
drivers/regulator/slg51000-regulator.c | 4 +--
drivers/regulator/sy8106a-regulator.c | 2 +-
drivers/regulator/sy8824x.c | 8 +++---
drivers/regulator/sy8827n.c | 4 +--
drivers/regulator/tps6286x-regulator.c | 10 ++++----
drivers/regulator/tps6287x-regulator.c | 10 ++++----
41 files changed, 119 insertions(+), 119 deletions(-)
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply
* [PATCH v5 07/19] drm/colorop: Create drm_atomic_helper_colorop_create_state()
From: Maxime Ripard @ 2026-05-19 9:01 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
to drm_private_obj") introduced a new pattern for allocating drm object
states.
Instead of relying on the reset() callback, it created a new
atomic_create_state hook. This is helpful because reset is a bit
overloaded: it's used to create the initial software state, reset it,
but also reset the hardware.
It can also be used either at probe time, to create the initial state
and possibly reset the hardware to an expected default, but also during
suspend/resume.
Both these cases come with different expectations too: during the
initialization, we want to initialize all states, but during
suspend/resume, drm_private_states for example are expected to be kept
around.
reset() also isn't fallible, which makes it harder to handle
initialization errors properly. This is only really relevant for some
drivers though, since all the helpers for reset only create a new
state, and don't touch the hardware at all.
It was thus decided to create a new hook that would allocate and
initialize a pristine state without any side effect:
atomic_create_state to untangle a bit some of it, and to separate the
initialization with the actual reset one might need during a
suspend/resume.
Continue the transition to the new pattern with drm_colorop.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_colorop.c | 23 +++++++++++++++++++++++
include/drm/drm_colorop.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 4c4d0a953e35..c0eecde8c176 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -521,10 +521,33 @@ static void __drm_colorop_state_init(struct drm_colorop_state *colorop_state,
&val))
colorop_state->curve_1d_type = val;
}
}
+/**
+ * drm_atomic_helper_colorop_create_state - Allocates and initializes colorop atomic state
+ * @colorop: drm colorop
+ *
+ * Initializes a pristine @drm_colorop_state.
+ *
+ * RETURNS:
+ * Pointer to new colorop state, or ERR_PTR on failure.
+ */
+struct drm_colorop_state *
+drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop)
+{
+ struct drm_colorop_state *state;
+
+ state = kzalloc_obj(*state);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ __drm_colorop_state_init(state, colorop);
+
+ return state;
+}
+
/**
* __drm_colorop_reset - reset state on colorop
* @colorop: drm colorop
* @colorop_state: colorop state to assign
*
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index c873199c60da..b4b9e4f558ab 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -423,10 +423,12 @@ int drm_plane_colorop_3dlut_init(struct drm_device *dev, struct drm_colorop *col
struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
uint32_t lut_size,
enum drm_colorop_lut3d_interpolation_type interpolation,
uint32_t flags);
+struct drm_colorop_state *
+drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop);
struct drm_colorop_state *
drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colorop);
void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
struct drm_colorop_state *state);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] arm64: cpucaps: Keep entries sorted
From: Fuad Tabba @ 2026-05-19 9:53 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel, Catalin Marinas, Mark Rutland, Marc Zyngier
In-Reply-To: <20260519092243.7278-1-will@kernel.org>
Hi Will,
On Tue, 19 May 2026 at 10:23, Will Deacon <will@kernel.org> wrote:
>
> The cpucaps list is supposed to be sorted, even though the awk script
> which processes it doesn't really care. Since this isn't enforced or
> relied upon and because the alphabet is hard, the list has gradually
> developed an ordering of its own.
>
> Re-sort the file.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Reported-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>
> Marc pointed out that HAS_BBML2_NOABORT was in the wrong place but, on
> closer inspection, there are a bunch of misplaced entries here. I
> honestly don't like the churn of re-sorting it, so an alternative is
> to live with it and remove the comment at the top asking people to keep
> it sorted it. Any preferences?
The resorting looks correct to me, but this is bound to drift unless
we enforce it. How about pairing it with enforcement, such as a `sort
-c` check in arch/arm64/tools/Makefile, or an awk rule in
gen-cpucaps.awk?
Otherwise, lgtm.
Reviewed-by: Fuad Tabba <tabba@google.com>
/fuad
>
> arch/arm64/tools/cpucaps | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index 811c2479e82d..0fc05b5026eb 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -5,6 +5,7 @@
> ALWAYS_BOOT
> ALWAYS_SYSTEM
> BTI
> +HAFT
> # Unreliable: use system_supports_32bit_el0() instead.
> HAS_32BIT_EL0_DO_NOT_USE
> HAS_32BIT_EL1
> @@ -14,6 +15,7 @@ HAS_ADDRESS_AUTH_ARCH_QARMA5
> HAS_ADDRESS_AUTH_IMP_DEF
> HAS_AMU_EXTN
> HAS_ARMv8_4_TTL
> +HAS_BBML2_NOABORT
> HAS_CACHE_DIC
> HAS_CACHE_IDC
> HAS_CNP
> @@ -26,41 +28,40 @@ HAS_ECV
> HAS_ECV_CNTPOFF
> HAS_EPAN
> HAS_EVT
> -HAS_FPMR
> HAS_FGT
> HAS_FGT2
> +HAS_FPMR
> HAS_FPSIMD
> HAS_GCS
> HAS_GENERIC_AUTH
> HAS_GENERIC_AUTH_ARCH_QARMA3
> HAS_GENERIC_AUTH_ARCH_QARMA5
> HAS_GENERIC_AUTH_IMP_DEF
> +HAS_GIC_PRIO_MASKING
> +HAS_GIC_PRIO_RELAXED_SYNC
> HAS_GICV3_CPUIF
> HAS_GICV5_CPUIF
> HAS_GICV5_LEGACY
> -HAS_GIC_PRIO_MASKING
> -HAS_GIC_PRIO_RELAXED_SYNC
> -HAS_ICH_HCR_EL2_TDIR
> HAS_HCR_NV1
> HAS_HCX
> +HAS_ICH_HCR_EL2_TDIR
> HAS_LDAPR
> HAS_LPA2
> -HAS_LSE_ATOMICS
> HAS_LS64
> HAS_LS64_V
> +HAS_LSE_ATOMICS
> HAS_LSUI
> HAS_MOPS
> HAS_NESTED_VIRT
> -HAS_BBML2_NOABORT
> HAS_PAN
> HAS_PMUV3
> -HAS_S1PIE
> -HAS_S1POE
> -HAS_SCTLR2
> HAS_RAS_EXTN
> HAS_RASV1P1_EXTN
> HAS_RNG
> +HAS_S1PIE
> +HAS_S1POE
> HAS_SB
> +HAS_SCTLR2
> HAS_STAGE2_FWB
> HAS_TCR2
> HAS_TIDCP1
> @@ -69,7 +70,6 @@ HAS_VA52
> HAS_VIRT_HOST_EXTN
> HAS_WFXT
> HAS_XNX
> -HAFT
> HW_DBM
> KVM_HVHE
> KVM_PROTECTED_MODE
> @@ -83,10 +83,10 @@ MTE_STORE_ONLY
> SME
> SME_FA64
> SME2
> +SPECTRE_BHB
> SPECTRE_V2
> SPECTRE_V3A
> SPECTRE_V4
> -SPECTRE_BHB
> SSBS
> SVE
> UNMAP_KERNEL_AT_EL0
> @@ -110,9 +110,6 @@ WORKAROUND_4193714
> WORKAROUND_4311569
> WORKAROUND_AMPERE_AC03_CPU_38
> WORKAROUND_AMPERE_AC04_CPU_23
> -WORKAROUND_TRBE_OVERWRITE_FILL_MODE
> -WORKAROUND_TSB_FLUSH_FAILURE
> -WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
> WORKAROUND_CAVIUM_23154
> WORKAROUND_CAVIUM_27456
> WORKAROUND_CAVIUM_30115
> @@ -128,3 +125,6 @@ WORKAROUND_REPEAT_TLBI
> WORKAROUND_SPECULATIVE_AT
> WORKAROUND_SPECULATIVE_SSBS
> WORKAROUND_SPECULATIVE_UNPRIV_LOAD
> +WORKAROUND_TRBE_OVERWRITE_FILL_MODE
> +WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
> +WORKAROUND_TSB_FLUSH_FAILURE
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [Linaro-mm-sig] Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Maxime Ripard @ 2026-05-19 9:52 UTC (permalink / raw)
To: Boris Brezillon
Cc: Chia-I Wu, Liviu Dudau, Marcin Ślusarz, Ketil Johnsen,
David Airlie, Simona Vetter, Maarten Lankhorst, Thomas Zimmermann,
Jonathan Corbet, Shuah Khan, Sumit Semwal, Benjamin Gaignard,
Brian Starkey, John Stultz, T.J. Mercier, Christian König,
Steven Price, Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <20260518091650.5a7a4f4a@fedora>
[-- Attachment #1: Type: text/plain, Size: 3983 bytes --]
Hi Boris,
On Mon, May 18, 2026 at 09:16:50AM +0200, Boris Brezillon wrote:
> On Wed, 13 May 2026 12:31:32 -0700
> Chia-I Wu <olvaffe@gmail.com> wrote:
>
> > On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
> > >
> > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 May 2026 14:47:27 +0100
> > > > Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > >
> > > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > > > >
> > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > > > return ret;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > > > >
> > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > > > name is "" already?
> > > > > > >
> > > > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > > > This check prevents that.
> > > > > >
> > > > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > > > currently probe and boot the FW even though we never setup the
> > > > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > > > just retry the next time a group with the protected bit is created and
> > > > > > fail if we can find a protected heap?
> > > > >
> > > > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > > > process when we have a group with protected mode set.
> > > >
> > > > No, but we can force a full/slow reset and have that thing
> > > > re-initialized, can't we? I mean, that's basically what we do when a
> > > > fast reset fails: we re-initialize all the sections and reset again, at
> > > > which point the FW should start from a fresh state, and be able to
> > > > properly initialize the protected-related stuff if protected sections
> > > > are populated. Am I missing something?
> > >
> > > Right, we can do that. For some reason I keep associating the reset with the
> > > error handling and not with "normal" operations.
> > I kind of hope we end up with either
> >
> > - panthor knows the exact heap to use and fails with EPROBE_DEFER if
> > the heap is missing, or
> > - panthor gets a dma-buf from userspace and does the full reset
> > - userspace also needs to provide a dma-buf for each protected
> > group for the suspend buffer
> >
> > than something in-between. The latter is more ad-hoc and basically
> > kicks the issue to the userspace.
>
> Indeed, the second option is more ad-hoc, but when you think about it,
> userspace has to have this knowledge, because it needs to know the
> dma-heap to use for buffer allocation that cross a device boundary
> anyway. Think about frames produced by a video decoder, and composited
> by the GPU into a protected scanout buffer that's passed to the KMS
> device. Why would the GPU driver be source of truth when it comes to
> choosing the heap to use to allocate protected buffers for the video
> decoder or those used for the display?
Just fyi, the trend is to go to devices listing the heaps userspace
should allocate from and/or using the heaps internally to allocate their
buffers, so that last part is where we're headed, and feels totally
reasonable to me.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v4 00/14] coco/TSM: Host-side Arm CCA IDE setup via connect/disconnect callbacks
From: Will Deacon @ 2026-05-19 9:46 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Aneesh Kumar K.V (Arm), linux-coco, kvmarm, linux-arm-kernel,
linux-kernel, Alexey Kardashevskiy, Catalin Marinas, Dan Williams,
Jason Gunthorpe, Jonathan Cameron, Marc Zyngier, Samuel Ortiz,
Steven Price, Xu Yilun
In-Reply-To: <afca6cdd-f9e3-4b5f-9f70-940c8dbb7a80@arm.com>
On Tue, May 19, 2026 at 09:24:07AM +0100, Suzuki K Poulose wrote:
> On 18/05/2026 13:59, Will Deacon wrote:
> > 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?
>
> Good point. RMI interface is only available for arm64 (not in Arm32). That
> said, it is indeed a firmware ! ;-) interface. The APIs are closely
> integrated with the KVM Realm management. If the general consensus is
> to move them under drivers/firmware (like PSCI), we could take that
> approach.
I'd certainly prefer that as it means it's co-located with other firmware
interface code and also means that the arch maintainers don't need to
worry about changes to driver code :p
Will
^ permalink raw reply
* [PATCH v5 14/19] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Maxime Ripard @ 2026-05-19 9:01 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
__drm_atomic_helper_connector_hdmi_reset() is typically used to
initialize a newly allocated drm_connector_state when the connector is
using the HDMI helpers, and is being called by the
drm_connector_funcs.reset implementation.
Since we want to consolidate DRM objects state allocation around the
atomic_create_state callback that will only allocate and initialize a
new drm_connector_state instance, we will need to call
__drm_atomic_helper_connector_hdmi_reset() from both the reset and
atomic_create hooks.
To avoid any confusion, we can thus rename
__drm_atomic_helper_connector_hdmi_reset() to
__drm_atomic_helper_connector_hdmi_state_init().
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 4 ++--
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 15 ++++++++-------
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
include/drm/display/drm_hdmi_state_helper.h | 4 ++--
6 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 649969fca141..50408af746d8 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -270,12 +270,12 @@ static void drm_bridge_connector_reset(struct drm_connector *connector)
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
drm_atomic_helper_connector_reset(connector);
if (bridge_connector->bridge_hdmi)
- __drm_atomic_helper_connector_hdmi_reset(connector,
- connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector,
+ connector->state);
}
static const struct drm_connector_funcs drm_bridge_connector_funcs = {
.reset = drm_bridge_connector_reset,
.detect = drm_bridge_connector_detect,
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 4867edbf2622..a331ebdd65af 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -304,29 +304,30 @@
* --kunitconfig=drivers/gpu/drm/tests \
* drm_atomic_helper_connector_hdmi_*
*/
/**
- * __drm_atomic_helper_connector_hdmi_reset() - Initializes all HDMI @drm_connector_state resources
+ * __drm_atomic_helper_connector_hdmi_state_init() - Initialize all HDMI @drm_connector_state resources
* @connector: DRM connector
- * @new_conn_state: connector state to reset
+ * @new_conn_state: connector state to initialize
*
* Initializes all HDMI resources from a @drm_connector_state without
* actually allocating it. This is useful for HDMI drivers, in
- * combination with __drm_atomic_helper_connector_reset() or
- * drm_atomic_helper_connector_reset().
+ * combination with __drm_atomic_helper_connector_state_init(),
+ * drm_atomic_helper_connector_reset(), or
+ * drm_atomic_helper_connector_create_state().
*/
-void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state)
+void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
{
unsigned int max_bpc = connector->max_bpc;
new_conn_state->max_bpc = max_bpc;
new_conn_state->max_requested_bpc = max_bpc;
new_conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
}
-EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
+EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_state_init);
static enum hdmi_colorspace
output_color_format_to_hdmi_colorspace(const struct drm_connector *connector,
enum drm_output_color_format fmt)
{
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 07e2afcb4f95..3cad8f9bc529 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -283,11 +283,11 @@ sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
}
static void sun4i_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
}
static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
.detect = sun4i_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
index c9819c3fc635..e89e1af7a811 100644
--- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
@@ -166,11 +166,11 @@ static const struct drm_connector_helper_funcs dummy_connector_helper_funcs = {
};
static void dummy_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
}
static const struct drm_connector_funcs dummy_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a161d3b00a25..74dce4be0c00 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -506,11 +506,11 @@ static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
}
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
drm_atomic_helper_connector_tv_margins_reset(connector);
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.force = drm_atomic_helper_connector_hdmi_force,
diff --git a/include/drm/display/drm_hdmi_state_helper.h b/include/drm/display/drm_hdmi_state_helper.h
index 0adc30c55ec9..13375bd0f4ae 100644
--- a/include/drm/display/drm_hdmi_state_helper.h
+++ b/include/drm/display/drm_hdmi_state_helper.h
@@ -9,12 +9,12 @@ struct drm_connector_state;
struct drm_display_mode;
struct hdmi_audio_infoframe;
enum drm_connector_status;
-void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state);
+void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state);
int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
struct drm_atomic_commit *state);
int drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *connector,
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox