* [PATCH v6 03/11] drm/msm/hdmi: switch to of_drm_get_bridge_by_endpoint()
From: Luca Ceresoli @ 2026-05-11 16:40 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Sumit Semwal, John Stultz, Tomi Valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel, Luca Ceresoli
In-Reply-To: <20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-0-f61c9e498b3f@bootlin.com>
This driver calls drm_of_find_panel_or_bridge() with a NULL pointer in the
@panel parameter, thus using a reduced feature set of that function.
Replace this call with the simpler of_drm_get_bridge_by_endpoint().
Since of_drm_get_bridge_by_endpoint() increases the refcount of the
returned bridge, ensure it is put on removal.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v6:
- move assignment of next_bridge earlier (avoid access before assignment)
Changes in v5:
- simplify error management code flow
Changes in v4:
- ensure next_bridge is put on later probe failures
Changes in v3:
- fix ERR_PTR deref when -ENODEV is returned
- move assignment of next_bridge earlier (avoid access before assignment)
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 70 +++++++++++++++++++++++++++--------------
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index d9491aac1a89..474006084633 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -285,19 +285,27 @@ static int msm_hdmi_dev_probe(struct platform_device *pdev)
spin_lock_init(&hdmi->reg_lock);
mutex_init(&hdmi->state_mutex);
- ret = drm_of_find_panel_or_bridge(dev_of_node(dev), 1, 0, NULL, &hdmi->next_bridge);
- if (ret && ret != -ENODEV)
- return ret;
+ hdmi->next_bridge = of_drm_get_bridge_by_endpoint(dev_of_node(dev), 1, 0);
+ if (IS_ERR(hdmi->next_bridge)) {
+ if (PTR_ERR(hdmi->next_bridge) != -ENODEV)
+ return PTR_ERR(hdmi->next_bridge);
+
+ hdmi->next_bridge = NULL;
+ }
hdmi->mmio = msm_ioremap(pdev, "core_physical");
- if (IS_ERR(hdmi->mmio))
- return PTR_ERR(hdmi->mmio);
+ if (IS_ERR(hdmi->mmio)) {
+ ret = PTR_ERR(hdmi->mmio);
+ goto err_put_bridge;
+ }
/* HDCP needs physical address of hdmi register */
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"core_physical");
- if (!res)
- return -EINVAL;
+ if (!res) {
+ ret = -EINVAL;
+ goto err_put_bridge;
+ }
hdmi->mmio_phy_addr = res->start;
hdmi->qfprom_mmio = msm_ioremap(pdev, "qfprom_physical");
@@ -307,45 +315,58 @@ static int msm_hdmi_dev_probe(struct platform_device *pdev)
}
hdmi->irq = platform_get_irq(pdev, 0);
- if (hdmi->irq < 0)
- return hdmi->irq;
+ if (hdmi->irq < 0) {
+ ret = hdmi->irq;
+ goto err_put_bridge;
+ }
hdmi->pwr_regs = devm_kcalloc(dev, config->pwr_reg_cnt,
sizeof(hdmi->pwr_regs[0]),
GFP_KERNEL);
- if (!hdmi->pwr_regs)
- return -ENOMEM;
+ if (!hdmi->pwr_regs) {
+ ret = -ENOMEM;
+ goto err_put_bridge;
+ }
for (i = 0; i < config->pwr_reg_cnt; i++)
hdmi->pwr_regs[i].supply = config->pwr_reg_names[i];
ret = devm_regulator_bulk_get(dev, config->pwr_reg_cnt, hdmi->pwr_regs);
- if (ret)
- return dev_err_probe(dev, ret, "failed to get pwr regulators\n");
+ if (ret) {
+ dev_err_probe(dev, ret, "failed to get pwr regulators\n");
+ goto err_put_bridge;
+ }
hdmi->pwr_clks = devm_kcalloc(dev, config->pwr_clk_cnt,
sizeof(hdmi->pwr_clks[0]),
GFP_KERNEL);
- if (!hdmi->pwr_clks)
- return -ENOMEM;
+ if (!hdmi->pwr_clks) {
+ ret = -ENOMEM;
+ goto err_put_bridge;
+ }
for (i = 0; i < config->pwr_clk_cnt; i++)
hdmi->pwr_clks[i].id = config->pwr_clk_names[i];
ret = devm_clk_bulk_get(dev, config->pwr_clk_cnt, hdmi->pwr_clks);
if (ret)
- return ret;
+ goto err_put_bridge;
+
hdmi->extp_clk = devm_clk_get_optional(dev, "extp");
- if (IS_ERR(hdmi->extp_clk))
- return dev_err_probe(dev, PTR_ERR(hdmi->extp_clk),
- "failed to get extp clock\n");
+ if (IS_ERR(hdmi->extp_clk)) {
+ ret = dev_err_probe(dev, PTR_ERR(hdmi->extp_clk),
+ "failed to get extp clock\n");
+ goto err_put_bridge;
+ }
hdmi->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
/* This will catch e.g. -EPROBE_DEFER */
- if (IS_ERR(hdmi->hpd_gpiod))
- return dev_err_probe(dev, PTR_ERR(hdmi->hpd_gpiod),
- "failed to get hpd gpio\n");
+ if (IS_ERR(hdmi->hpd_gpiod)) {
+ ret = dev_err_probe(dev, PTR_ERR(hdmi->hpd_gpiod),
+ "failed to get hpd gpio\n");
+ goto err_put_bridge;
+ }
if (!hdmi->hpd_gpiod)
DBG("failed to get HPD gpio");
@@ -355,7 +376,7 @@ static int msm_hdmi_dev_probe(struct platform_device *pdev)
ret = msm_hdmi_get_phy(hdmi);
if (ret)
- return ret;
+ goto err_put_bridge;
ret = devm_pm_runtime_enable(dev);
if (ret)
@@ -371,6 +392,8 @@ static int msm_hdmi_dev_probe(struct platform_device *pdev)
err_put_phy:
msm_hdmi_put_phy(hdmi);
+err_put_bridge:
+ drm_bridge_put(hdmi->next_bridge);
return ret;
}
@@ -381,6 +404,7 @@ static void msm_hdmi_dev_remove(struct platform_device *pdev)
component_del(&pdev->dev, &msm_hdmi_ops);
msm_hdmi_put_phy(hdmi);
+ drm_bridge_put(hdmi->next_bridge);
}
static int msm_hdmi_runtime_suspend(struct device *dev)
--
2.54.0
^ permalink raw reply related
* [PATCH v6 02/11] drm/bridge: add of_drm_get_bridge_by_endpoint()
From: Luca Ceresoli @ 2026-05-11 16:40 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Sumit Semwal, John Stultz, Tomi Valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel, Luca Ceresoli,
Dmitry Baryshkov, Laurent Pinchart
In-Reply-To: <20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-0-f61c9e498b3f@bootlin.com>
drm_of_find_panel_or_bridge() is widely used, but many callers pass NULL
into the @panel or the @bridge arguments, thus making a very partial usage
of this rather complex function.
Besides, the bridge returned in @bridge is not refcounted, thus making this
API unsafe when DRM bridge hotplug will be introduced.
Solve both issues for the cases of calls to drm_of_find_panel_or_bridge()
with a NULL @panel pointer by adding a new function that only looks for
bridges (and is thus much simpler) and increments the refcount of the
returned bridge.
The new function is identical to drm_of_find_panel_or_bridge() except it:
- handles bridge refcounting: uses of_drm_find_and_get_bridge() instead of
of_drm_find_bridge() internally to return a refcounted bridge
- is simpler to use: just takes no @panel parameter, returns the pointer
in the return value instead of a double pointer argument
- has a simpler implementation: it is equal to
drm_of_find_panel_or_bridge() after removing the code that becomes dead
when @panel == NULL
Also add this function to drm_bridge.c and not drm_of.c because it returns
bridges only.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v5:
- add missing ERR_PTR() in return statement for no-OF inline variant
Changes in v4:
- update function declaration in non-OF case
- fix grammar in comment
Changes in v2:
- return the bridge in the return value, not a double pointer
---
drivers/gpu/drm/drm_bridge.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/drm/drm_bridge.h | 7 +++++++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index b46c01db8d83..687b36eea0c7 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -1582,6 +1582,47 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
return bridge;
}
EXPORT_SYMBOL(of_drm_find_bridge);
+
+/**
+ * of_drm_get_bridge_by_endpoint - return DRM bridge connected to a port/endpoint
+ * @np: device tree node containing output ports
+ * @port: port in the device tree node, or -1 for the first port found
+ * @endpoint: endpoint in the device tree node, or -1 for the first endpoint found
+ *
+ * Given a DT node's port and endpoint number, find the connected node and
+ * return the associated drm_bridge device.
+ *
+ * The refcount of the returned bridge is incremented. Use drm_bridge_put()
+ * when done with it.
+ *
+ * Returns a pointer to the connected drm_bridge, or a negative error on failure
+ */
+struct drm_bridge *of_drm_get_bridge_by_endpoint(const struct device_node *np,
+ int port, int endpoint)
+{
+ struct drm_bridge *bridge;
+
+ /*
+ * of_graph_get_remote_node() produces a noisy error message if port
+ * node isn't found and the absence of the port is a legit case here,
+ * so at first we silently check whether graph is present in the
+ * device-tree node.
+ */
+ if (!of_graph_is_present(np))
+ return ERR_PTR(-ENODEV);
+
+ struct device_node *remote __free(device_node) =
+ of_graph_get_remote_node(np, port, endpoint);
+ if (!remote)
+ return ERR_PTR(-ENODEV);
+
+ bridge = of_drm_find_and_get_bridge(remote);
+ if (!bridge)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return bridge;
+}
+EXPORT_SYMBOL_GPL(of_drm_get_bridge_by_endpoint);
#endif
/**
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index fdac9a526f38..4ba3a5deef9a 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -1327,6 +1327,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
#ifdef CONFIG_OF
struct drm_bridge *of_drm_find_and_get_bridge(struct device_node *np);
struct drm_bridge *of_drm_find_bridge(struct device_node *np);
+struct drm_bridge *of_drm_get_bridge_by_endpoint(const struct device_node *np,
+ int port, int endpoint);
#else
static inline struct drm_bridge *of_drm_find_and_get_bridge(struct device_node *np)
{
@@ -1336,6 +1338,11 @@ static inline struct drm_bridge *of_drm_find_bridge(struct device_node *np)
{
return NULL;
}
+static inline struct drm_bridge *of_drm_get_bridge_by_endpoint(const struct device_node *np,
+ int port, int endpoint)
+{
+ return ERR_PTR(-ENODEV);
+}
#endif
static inline bool drm_bridge_is_last(struct drm_bridge *bridge)
--
2.54.0
^ permalink raw reply related
* [PATCH v6 01/11] drm/bridge: drm_bridge_put(): ignore ERR_PTR
From: Luca Ceresoli @ 2026-05-11 16:40 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Sumit Semwal, John Stultz, Tomi Valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel, Luca Ceresoli,
Laurent Pinchart, Dmitry Baryshkov, Laurent Pinchart
In-Reply-To: <20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-0-f61c9e498b3f@bootlin.com>
Most functions returning a struct drm_bridge pointer currently return a
valid pointer or NULL, but this restricts their ability to return an error
code as an ERR_PTR describing the error kind.
In preparation to have new APIs that can return a struct drm_bridge pointer
holding an ERR_PTR (and for those which already do) make drm_bridge_put()
ignore ERR_PTR values, just like it ignores NULL pointers.
This will avoid annoying error checking in many places and the risk of
missing error checks.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/all/20260318152533.GA633439@killaraus.ideasonboard.com/
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/all/omlnswxukeqgnatzdvooaashgkfcacjevkvbkm6xt33itgua2k@jcmzll2w6kdq/
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v5:
- don't change drm_bridge_get(), only drm_bridge_put() has known use cases
Changes in v4:
- removed incorrect change to drm_bridge_clear_and_put() kdoc
Patch added in v2
---
drivers/gpu/drm/drm_bridge.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index ce180f0b26b2..b46c01db8d83 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -300,7 +300,7 @@ EXPORT_SYMBOL(drm_bridge_get);
/**
* drm_bridge_put - Release a bridge reference
- * @bridge: DRM bridge; if NULL this function does nothing
+ * @bridge: DRM bridge; if NULL or an ERR_PTR this function does nothing
*
* This function decrements the bridge's reference count and frees the
* object if the reference count drops to zero.
@@ -310,7 +310,7 @@ EXPORT_SYMBOL(drm_bridge_get);
*/
void drm_bridge_put(struct drm_bridge *bridge)
{
- if (bridge)
+ if (!IS_ERR_OR_NULL(bridge))
kref_put(&bridge->refcount, __drm_bridge_free);
}
EXPORT_SYMBOL(drm_bridge_put);
--
2.54.0
^ permalink raw reply related
* [PATCH v6 00/11] drm/bridge: handle refcounting for bridge-only callers of drm_of_find_panel_or_bridge()
From: Luca Ceresoli @ 2026-05-11 16:40 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Sumit Semwal, John Stultz, Tomi Valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel, Luca Ceresoli,
Laurent Pinchart, Dmitry Baryshkov, Laurent Pinchart, Biju Das
This series converts all the bridge-only callers of the deprecated
drm_of_find_panel_or_bridge() API to a new, simpler API that handles bridge
refcounting.
All patches acked/reviewed except patches 3 and 4.
== Series description
* Patch 1 (new in v2) makes drm_bridge_put() ignore ERR_PTR pointers,
not only NULL pointers
* Patch 2 introduces of_drm_get_bridge_by_endpoint() as a replacement for
bridge-only calls to drm_of_find_panel_or_bridge(); the new function
refcounts the bridge and is simpler
* The following patches convert all bridge-only users to the new API
* The last patch forbids new bridge-only calls to
drm_of_find_panel_or_bridge()
== 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. ➜ convert bridge-only drm_of_find_panel_or_bridge() users
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)
B. Device tree description
[0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v6:
- Patch 2: fix warning in the no-OF case
- Patch 3: fix too-late next_bridge assignment
- Link to v5: https://patch.msgid.link/20260507-drm-bridge-alloc-getput-panel_or_bridge-v5-0-472b913b5cb7@bootlin.com
Changes in v5:
- Patch 1: change drm_bridge_put() only
- Patches 3,10: simplify error management code flow
- Link to v4: https://patch.msgid.link/20260504-drm-bridge-alloc-getput-panel_or_bridge-v4-0-b578c3daaf10@bootlin.com
Changes in v4:
- Fixed patches 3 and 10
- Minor fixes to patches 1 and 2
- Removed bouncing addresses yongqin.liu@linaro.org and
xinliang.liu@linaro.org from Cc
- Link to v3: https://patch.msgid.link/20260428-drm-bridge-alloc-getput-panel_or_bridge-v3-0-a537b5567add@bootlin.com
Changes in v3:
- patch 3, 8, 10: fixed ERR_PTR deref in the -ENODEV case, and removed
Dmitry's R-by from those patches as they are changed
- Added review trailers to the other patches
- Link to v2: https://patch.msgid.link/20260428-drm-bridge-alloc-getput-panel_or_bridge-v2-0-4300744a1c47@bootlin.com
Changes in v2:
- Added patch to ignore ERR_PTR values in drm_bridge_get/put()
- Changed API to return the bridge (or a ERR_PTR) in the return value,
not as a double-pointer output parameter
- Adapted all patches to the new API, dropped Dmitry's review tags as the
patches are all modified
- Removed bouncing addresses from Cc list
- Link to v1: https://patch.msgid.link/20260413-drm-bridge-alloc-getput-panel_or_bridge-v1-0-acd01cd79a1f@bootlin.com
---
Luca Ceresoli (11):
drm/bridge: drm_bridge_put(): ignore ERR_PTR
drm/bridge: add of_drm_get_bridge_by_endpoint()
drm/msm/hdmi: switch to of_drm_get_bridge_by_endpoint()
drm/hisilicon/kirin: switch to of_drm_get_bridge_by_endpoint()
drm/bridge: chrontel-ch7033: switch to of_drm_get_bridge_by_endpoint()
drm/bridge: lontium-lt9611uxc: switch to of_drm_get_bridge_by_endpoint()
drm/bridge: lt9611: switch to of_drm_get_bridge_by_endpoint()
drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
drm/bridge: lt8713sx: switch to of_drm_get_bridge_by_endpoint()
drm: zynqmp_dp: switch to of_drm_get_bridge_by_endpoint()
drm: of: forbid bridge-only calls to drm_of_find_panel_or_bridge()
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 +++---
drivers/gpu/drm/bridge/chrontel-ch7033.c | 28 ++++++-----
drivers/gpu/drm/bridge/lontium-lt8713sx.c | 10 ++--
drivers/gpu/drm/bridge/lontium-lt9611.c | 9 ++--
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 9 ++--
drivers/gpu/drm/drm_bridge.c | 45 +++++++++++++++++-
drivers/gpu/drm/drm_of.c | 26 +++++------
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 9 ++--
drivers/gpu/drm/msm/hdmi/hdmi.c | 70 +++++++++++++++++++---------
drivers/gpu/drm/xlnx/zynqmp_dp.c | 19 ++++----
include/drm/drm_bridge.h | 7 +++
12 files changed, 162 insertions(+), 86 deletions(-)
---
base-commit: 7af78cfbe2b47cd9ecb61480fb74d64b584d8a94
change-id: 20260410-drm-bridge-alloc-getput-panel_or_bridge-42501b38eaad
Best regards,
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-11 16:38 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel, Sean Christopherson, Jim Mattson
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Raghavendra Rao Ananta, Eric Auger,
Kees Cook, Arnd Bergmann, Nathan Chancellor, linux-arm-kernel,
kvmarm, linux-kselftest
In-Reply-To: <6afc4b95-3c15-4d71-877d-19b84e91ce05@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
On Mon, 2026-05-11 at 17:14 +0200, Paolo Bonzini wrote:
> On 5/11/26 10:57, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Document the expectation that KVM maintains guest-visible compatibility
> > across host kernel upgrades and rollbacks. Specifically:
> >
> > - State saved/restored via KVM ioctls must be sufficient for live
> > migration (and live update) between kernel versions.
> >
> > - Where a new kernel introduces a guest-visible change, it provides a
> > mechanism for userspace to select the previous behaviour.
> >
> > - This allows both forward migration (upgrade) and backward migration
> > (rollback) of guests.
> >
> > These expectations have been implicitly required on x86 but were not
> > explicitly documented. Harmonise the expectations across all of KVM.
>
> One big part of achieving this on x86 is the handling of CPUID. Despite
> all the mess that KVM_SET_CPUID2 is (and sometimes the underlying
> architecture too, as Jim Mattson would certainly agree), KVM is
> generally able to provide a consistent view of its configuration to the
> guest. This doesn't quite extend to compatibility across vendors, but
> it does work across processor generations from either Intel or AMD.
Right. For x86 this is largely covered by CPUID. If you launch a guest
on a new kernel, using the same CPUID bits as an older kernel, then
your guest will mostly not see anything new. And will be migratable to
that older kernel without issue.
Not *everything* is in CPUID; one recent exception that comes to mind
is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
existing behaviour of older kernels — even when that behaviour doesn't
make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
*advertise* the feature, but not actually *implement* it. Nevertheless,
that remains the default behaviour of future kernels unless userspace
explicitly opts in to fully enable (or disable) the feature.
But this documentation update isn't even asking for that compatible-by-
default behaviour, even though that is the right thing to do. It's only
asking that it be *possible* to reinstate the old behaviour, for
userspace that *knows* about the change and explicitly wants to go back
to the old way to remain compatible.
And sadly, KVM/arm64 doesn't even meet *that* low bar.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
From: Conor Dooley @ 2026-05-11 16:34 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <d51ab76d9f658aad542fa24651d1083e31628038.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]
On Mon, May 11, 2026 at 06:18:22PM +0200, Alexander Sverdlin wrote:
> Hi Conor,
>
> On Mon, 2026-05-11 at 17:08 +0100, Conor Dooley wrote:
> > > Baijie HelperBoard A133 is a development board around their A133 Core
> > > board. Introduce a compatible for both the Core and the development
> > > boards.
> > >
> > > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> > > ---
> > >
> > > Changelog:
> > > v2:
> > > - introduced baijie,helper-a133-core compatible for the Core (SoM) board
> > >
> > > Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > index e6443c266fa1..d7b9dec81165 100644
> > > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > @@ -96,6 +96,17 @@ properties:
> > > - const: allwinner,ba10-tvbox
> > > - const: allwinner,sun4i-a10
> > >
> > > +
> > > + - description: HelperBoardA133 Core
> > > + items:
> > > + - const: baijie,helper-a133-core
> > > + - const: allwinner,sun50i-a100
> >
> > Does this make sense? Can the core board be used without a carrier?
>
> such operation would be impractical at least, that's why in my v1
> Core board didn't have its own compatible. Maybe I didn't understand
> you correctly.
I just wanted a comaptible for the SoM, so that there's a common
compatible for that if it ends up on another carrier. IIRC these Baijie
folks had another one on their site, but may be misremembering.
>
> Shall I drop the above 4 lines, the compatible property from the
> root in sun50i-a133-baije-core.dtsi and only leave
> sun50i-a133-baijie-helper.dtb with 3-strings compatible as it is
> now in v2?
> > > + - description: Baijie Helper A133
> > > + items:
> > > + - const: baijie,helper-a133
> > > + - const: baijie,helper-a133-core
> > > + - const: allwinner,sun50i-a100
What I wanted was just this, so trim it down to that and you can add
my Acked-by: Conor Dooley <conor.dooley@microchip.com>
~heers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 1/3] phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
From: Radhey Shyam Pandey @ 2026-05-11 16:31 UTC (permalink / raw)
To: laurent.pinchart, vkoul, neil.armstrong, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, git,
Nava kishore Manne, stable, Radhey Shyam Pandey
In-Reply-To: <20260511163135.2924642-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
The L0_TX_DIG_61 register bit 2 is a reserved read-only field.
The previous mask value 0x0f incorrectly included bit 2, causing
unintended writes to a reserved bit on every scrambler bypass
operation.
Correct the mask to (BIT(3) | GENMASK(1, 0)) to cover only the
valid scramble bypass control bits.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index fe6b4925d166..c037d7c13d48 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -53,7 +53,7 @@
#define L0_TM_DIG_6 0x106c
#define L0_TM_DIS_DESCRAMBLE_DECODER 0x0f
#define L0_TX_DIG_61 0x00f4
-#define L0_TM_DISABLE_SCRAMBLE_ENCODER 0x0f
+#define L0_TM_DISABLE_SCRAMBLE_ENCODER (BIT(3) | GENMASK(1, 0))
/* PLL Test Mode register parameters */
#define L0_TM_PLL_DIG_37 0x2094
--
2.44.4
^ permalink raw reply related
* [PATCH 0/3] phy: zynqmp: fix SERDES scrambler register handling and enable for USB
From: Radhey Shyam Pandey @ 2026-05-11 16:31 UTC (permalink / raw)
To: laurent.pinchart, vkoul, neil.armstrong, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, git,
Radhey Shyam Pandey
This series fixes three related issues in the ZynqMP SERDES PHY
scrambler/encoder bypass path:
1. The L0_TM_DISABLE_SCRAMBLE_ENCODER mask incorrectly included bit 2
of L0_TX_DIG_61, which is a reserved read-only field. Correct the
mask to (BIT(3) | GENMASK(1, 0)).
2. xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which
performs a full register write, clobbering unrelated bits. Switch
to xpsgtr_clr_set_phy() with clr=mask, set=mask to preserve other
register fields.
3. USB Gen1 requires PHY-side scrambling and 8b/10b encoding as
mandated by the USB 3.x specification. The driver was incorrectly
bypassing these for USB, the same as SATA and SGMII where encoding
is handled in the controller.
Nava kishore Manne (3):
phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
phy: zynqmp: use read-modify-write for SERDES scrambler bypass
phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
drivers/phy/xilinx/phy-zynqmp.c | 37 ++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
2.44.4
^ permalink raw reply
* [PATCH 3/3] phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
From: Radhey Shyam Pandey @ 2026-05-11 16:31 UTC (permalink / raw)
To: laurent.pinchart, vkoul, neil.armstrong, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, git,
Nava kishore Manne, stable, Radhey Shyam Pandey
In-Reply-To: <20260511163135.2924642-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
USB Gen1 requires scrambling and 8b/10b encoding to be performed in the
physical layer. Do not bypass PHY-side scrambler or encoder/decoder for
USB operation, as mandated by the USB 3.x specification.
Scrambler and 8b/10b bypass remain restricted to SATA and SGMII
modes, where encoding is handled in the controller.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 39 ++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index 6c56c4df8523..087fe402e4e2 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -502,15 +502,30 @@ static void xpsgtr_lane_set_protocol(struct xpsgtr_phy *gtr_phy)
}
}
-/* Bypass (de)scrambler and 8b/10b decoder and encoder. */
-static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy)
+/**
+ * xpsgtr_bypass_scrambler_8b10b - Configure scrambler/encoder behavior
+ * @gtr_phy: pointer to lane context
+ * @bypass: true to enable scrambler/encoder bypass (SATA/SGMII),
+ * false to disable scrambler/encoder bypass (USB3)
+ *
+ * Uses RMW to preserve reserved and unrelated register fields.
+ */
+static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy,
+ bool bypass)
{
- xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
- L0_TM_DIS_DESCRAMBLE_DECODER,
- L0_TM_DIS_DESCRAMBLE_DECODER);
- xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
- L0_TM_DISABLE_SCRAMBLE_ENCODER,
- L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ if (bypass) {
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER,
+ L0_TM_DIS_DESCRAMBLE_DECODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ } else {
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER, 0);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER, 0);
+ }
}
/* DP-specific initialization. */
@@ -531,7 +546,7 @@ static void xpsgtr_phy_init_sata(struct xpsgtr_phy *gtr_phy)
{
struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
- xpsgtr_bypass_scrambler_8b10b(gtr_phy);
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, true);
writel(gtr_phy->lane, gtr_dev->siou + SATA_CONTROL_OFFSET);
}
@@ -547,7 +562,7 @@ static void xpsgtr_phy_init_sgmii(struct xpsgtr_phy *gtr_phy)
xpsgtr_clr_set(gtr_dev, TX_PROT_BUS_WIDTH, mask, val);
xpsgtr_clr_set(gtr_dev, RX_PROT_BUS_WIDTH, mask, val);
- xpsgtr_bypass_scrambler_8b10b(gtr_phy);
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, true);
}
/* Configure TX de-emphasis and margining for DP. */
@@ -707,6 +722,10 @@ static int xpsgtr_phy_init(struct phy *phy)
case ICM_PROTOCOL_SGMII:
xpsgtr_phy_init_sgmii(gtr_phy);
break;
+
+ case ICM_PROTOCOL_USB:
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, false);
+ break;
}
out:
--
2.44.4
^ permalink raw reply related
* [PATCH 2/3] phy: zynqmp: use read-modify-write for SERDES scrambler bypass
From: Radhey Shyam Pandey @ 2026-05-11 16:31 UTC (permalink / raw)
To: laurent.pinchart, vkoul, neil.armstrong, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, git,
Nava kishore Manne, stable, Radhey Shyam Pandey
In-Reply-To: <20260511163135.2924642-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which performs
a full register write, silently clearing any bits beyond the intended
bypass control fields.
Switch to xpsgtr_clr_set_phy() with clr=mask, set=mask to set only
the bypass bits while preserving the remaining bits in each register.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index c037d7c13d48..6c56c4df8523 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -505,8 +505,12 @@ static void xpsgtr_lane_set_protocol(struct xpsgtr_phy *gtr_phy)
/* Bypass (de)scrambler and 8b/10b decoder and encoder. */
static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy)
{
- xpsgtr_write_phy(gtr_phy, L0_TM_DIG_6, L0_TM_DIS_DESCRAMBLE_DECODER);
- xpsgtr_write_phy(gtr_phy, L0_TX_DIG_61, L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER,
+ L0_TM_DIS_DESCRAMBLE_DECODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER);
}
/* DP-specific initialization. */
--
2.44.4
^ permalink raw reply related
* Re: [PATCH v19 0/7] ring-buffer: Making persistent ring buffers robust
From: Steven Rostedt @ 2026-05-11 16:29 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <20260507131416.35bc304d89f974ae3b33d20b@kernel.org>
On Thu, 7 May 2026 13:14:16 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > I'll test this some more, and make a proper patch.
>
> Ah, indeed. Thanks for fixing!
>
> BTW, shouldn't we unify common logic of those functions?
Hmm, there's not much common between the two. One is a consuming read and
the other is a non-consuming read that needs to test for a bunch of race
conditions.
If you see something that can be shared, I'm all for it.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Conor Dooley @ 2026-05-11 16:27 UTC (permalink / raw)
To: Arnab Layek
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260511121004.2984149-2-arnab.layek@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]
On Mon, May 11, 2026 at 08:10:04PM +0800, Arnab Layek wrote:
> The MT8188 SCP requires two reserved memory regions:
> 1. Main SCP SRAM memory region (required)
> 2. SCP L1TCM memory region (optional, for additional memory)
>
> Some other MediaTek SoCs only use a single memory region. This patch adds
> a conditional schema using if/then to allow 1-2 memory regions
> specifically for mediatek,mt8188-scp and mediatek,mt8188-scp-dual
> compatibles, while keeping the default maxItems: 1 for other
> SoCs.
>
> Each memory region is documented with descriptions to
> clarify their purpose, following the pattern used in other bindings.
>
> Signed-off-by: Arnab Layek <arnab.layek@mediatek.com>
> ---
> .../bindings/remoteproc/mtk,scp.yaml | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> index bdbb12118da4..df13be2026a6 100644
> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> @@ -205,6 +205,27 @@ allOf:
> items:
> - const: cfg
> - const: l1tcm
> + - if:
> + properties:
> + compatible:
> + enum:
> + - mediatek,mt8188-scp
> + - mediatek,mt8188-scp-dual
> + then:
> + properties:
> + memory-region:
> + minItems: 1
> + items:
> + - description: Main SCP SRAM memory region
> + - description: Optional SCP L1TCM memory region
> + patternProperties:
> + "^scp@[a-f0-9]+$":
> + properties:
> + memory-region:
> + minItems: 1
> + items:
> + - description: Main SCP SRAM memory region
> + - description: Optional SCP L1TCM memory region
Does this even work, given that memory-region has maxItems: 1 outside
the conditional section?
Cheers,
Conor.
>
> additionalProperties: false
>
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: David Lechner @ 2026-05-11 16:24 UTC (permalink / raw)
To: Jonathan Cameron, Pramod Maurya
Cc: Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michal Simek, Lars-Peter Clausen, linux-iio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260511171554.6541042b@jic23-huawei>
On 5/11/26 11:15 AM, Jonathan Cameron wrote:
> On Sun, 10 May 2026 08:01:36 -0400
> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>
>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>> from the legacy plain-text format to a YAML schema, enabling automated
>> validation with dt-schema.
>>
>> The new binding covers the same hardware and compatible strings:
>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>
>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
> Hi Pramod,
>
> Something went wrong with your sending of v3. I have two versions sent
> half a day apart and no idea how they are related.
>
> Anyhow one of them got feedback from Rob's bot so I'll assume we are
> getting a v4 and wait for that.
>
> Jonathan
I think Rob will have to fix the bot to make an exception for the
legacy bindings. This should have been called out in the commit message
as requested in a previous revision.
https://lore.kernel.org/linux-iio/20260220053941.611415-6-sai.krishna.potthuri@amd.com/
^ permalink raw reply
* Re: [PATCH v3 0/4] ROCK 4D audio enablement
From: Nicolas Frattaroli @ 2026-05-11 16:21 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Krzysztof Kozlowski, Cristian Ciocaltea
In-Reply-To: <20260408-rock4d-audio-v3-0-49e43c3c2a68@collabora.com>
Hi Alexandre, and other maintainers,
On Wednesday, 8 April 2026 19:49:38 Central European Summer Time Nicolas Frattaroli wrote:
> The ROCK 4D uses an ADC input to distinguish between a headphone (i.e.,
> no mic) and a headset (i.e., with mic). After some searching, it appears
> that the closest we can get to modelling this is by sending a particular
> switch input event.
>
> So this series modifies the adc-keys bindings, extends the adc-keys
> driver to allow sending other input types as well, and then adds the
> analog audio nodes to ROCK 4D's device tree.
>
> It should be noted that analog capture from the TRRS jack currently
> results in completely digitally silent audio for me, i.e. no data other
> than 0xFF. There's a few reasons why this could happen, chief among them
> that my SAI driver is broken or that the ES8328 codec driver is once
> again broken. The DAPM routes when graphed out look fine though. So the
> DTS part is correct, and I can fix the broken capture in a separate
> follow-up patch that doesn't have to include DT people.
>
> Another possibility is that my phone headset, despite being 4 rings and
> having a little pin hole at the back of the volume doodad, does not
> actually have a microphone, but in that case I'd still expect some noise
> in the PCM. Maybe it's just shy.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> Changes in v3:
> - bindings: use unevaluatedProperties instead of explicitly mentioning
> linux,input-type.
> - Link to v2: https://lore.kernel.org/r/20251215-rock4d-audio-v2-0-82a61de39b4c@collabora.com
>
> Changes in v2:
> - Drop HDMI audio patch, as it was already merged.
> - adc-keys: rename "keycode" to "code".
> - adc-keys: make the keycode (now "code") local a u32 instead of an int
> - adc-keys: only allow EV_KEY and EV_SW for now. Rename patch
> accordingly.
> - adc-keys: Add another patch to rework probe function error logging.
> - Link to v1: https://lore.kernel.org/r/20250630-rock4d-audio-v1-0-0b3c8e8fda9c@collabora.com
>
> ---
> Nicolas Frattaroli (4):
> dt-bindings: input: adc-keys: allow all input properties
> Input: adc-keys - support EV_SW as well, not just EV_KEY.
> Input: adc-keys - Use dev_err_probe in probe function
> arm64: dts: rockchip: add analog audio to ROCK 4D
>
> .../devicetree/bindings/input/adc-keys.yaml | 17 ++--
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 90 ++++++++++++++++++++++
> drivers/input/keyboard/adc-keys.c | 88 ++++++++++-----------
> 3 files changed, 147 insertions(+), 48 deletions(-)
> ---
> base-commit: 8de395f35e79d9168a78504fed495578ec7bac52
> change-id: 20250627-rock4d-audio-cfc07f168a08
>
> Best regards,
> --
> Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
>
What's the path forward here? All the patches are reviewed, but it
has been almost a month without them being applied now.
Which tree(s) would this be applied to, and who should I poke?
Thanks :)
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: mfd: st,stmpe: fix PWM schema and drop legacy binding
From: Conor Dooley @ 2026-05-11 16:19 UTC (permalink / raw)
To: Manish Baing
Cc: lee, ukleinek, linusw, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, linux-pwm
In-Reply-To: <20260509193928.19030-1-manishbaing2789@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Vinod Koul @ 2026-05-11 16:18 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Neil Armstrong, Heiko Stuebner, Algea Cao, Dmitry Baryshkov,
kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <c76d7020-2b3b-4f30-ab40-a8442c953966@collabora.com>
On 10-05-26, 11:55, Cristian Ciocaltea wrote:
> Hi Vinod,
>
> On 5/10/26 10:36 AM, Vinod Koul wrote:
> > On 27-02-26, 22:48, Cristian Ciocaltea wrote:
> >> This series provides a set of bug fixes and cleanups for the Rockchip
> >> Samsung HDPTX PHY driver.
> >>
> >> The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
> >> calculation and synchronization issues. Specifically, it fixes edge
> >> cases where the PHY PLL is pre-programmed by an external component (like
> >> a bootloader) or when changing the color depth (bpc) while keeping the
> >> modeline constant. Because the Common Clock Framework .set_rate()
> >> callback might not be invoked if the pixel clock remains unchanged, this
> >> previously led to out-of-sync states between CCF and the actual HDMI PHY
> >> configuration.
> >>
> >> The second part focuses on code cleanups and modernizing the register
> >> access. Now that dw_hdmi_qp driver has fully switched to using
> >> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
> >> and the restrict_rate_change flag logic. Finally, it refactors the
> >> driver to consistently use standard bitfield macros.
> >
> > Sorry looks like I have missed to review this one.
> > Can you please rebase on phy/fixes and send...
>
> I've just verified and it applies cleanly on top of phy/fixes.
> Do you still need a resend?
Yes please, it didnt apply for me
--
~Vinod
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: Jonathan Cameron @ 2026-05-11 16:17 UTC (permalink / raw)
To: Pramod Maurya
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Lars-Peter Clausen, linux-iio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260510120141.118057-1-pramod.nexgen@gmail.com>
On Sun, 10 May 2026 08:01:36 -0400
Pramod Maurya <pramod.nexgen@gmail.com> wrote:
> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
> from the legacy plain-text format to a YAML schema, enabling automated
> validation with dt-schema.
>
> The new binding covers the same hardware and compatible strings:
> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
> - xlnx,axi-xadc-1.00.a (AXI softmacro)
> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>
> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
On another note - please slow down. I now see that v1-3 all came in less
than 2 days. Typically wait around a week for a significant patch like
this - that gives time for multiple reviewers to take a look.
Maybe we can relax that given the v3 many versions confusion - but I would
still wait a day or so before sending a v4
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
From: Alexander Sverdlin @ 2026-05-11 16:18 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260511-stock-elitism-f1f703bee1a3@spud>
Hi Conor,
On Mon, 2026-05-11 at 17:08 +0100, Conor Dooley wrote:
> > Baijie HelperBoard A133 is a development board around their A133 Core
> > board. Introduce a compatible for both the Core and the development
> > boards.
> >
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> > ---
> >
> > Changelog:
> > v2:
> > - introduced baijie,helper-a133-core compatible for the Core (SoM) board
> >
> > Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > index e6443c266fa1..d7b9dec81165 100644
> > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > @@ -96,6 +96,17 @@ properties:
> > - const: allwinner,ba10-tvbox
> > - const: allwinner,sun4i-a10
> >
> > + - description: Baijie Helper A133
> > + items:
> > + - const: baijie,helper-a133
> > + - const: baijie,helper-a133-core
> > + - const: allwinner,sun50i-a100
> > +
> > + - description: HelperBoardA133 Core
> > + items:
> > + - const: baijie,helper-a133-core
> > + - const: allwinner,sun50i-a100
>
> Does this make sense? Can the core board be used without a carrier?
such operation would be impractical at least, that's why in my v1
Core board didn't have its own compatible. Maybe I didn't understand
you correctly.
Shall I drop the above 4 lines, the compatible property from the
root in sun50i-a133-baije-core.dtsi and only leave
sun50i-a133-baijie-helper.dtb with 3-strings compatible as it is
now in v2?
--
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: Jonathan Cameron @ 2026-05-11 16:15 UTC (permalink / raw)
To: Pramod Maurya
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Lars-Peter Clausen, linux-iio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260510120141.118057-1-pramod.nexgen@gmail.com>
On Sun, 10 May 2026 08:01:36 -0400
Pramod Maurya <pramod.nexgen@gmail.com> wrote:
> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
> from the legacy plain-text format to a YAML schema, enabling automated
> validation with dt-schema.
>
> The new binding covers the same hardware and compatible strings:
> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
> - xlnx,axi-xadc-1.00.a (AXI softmacro)
> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>
> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
Hi Pramod,
Something went wrong with your sending of v3. I have two versions sent
half a day apart and no idea how they are related.
Anyhow one of them got feedback from Rob's bot so I'll assume we are
getting a v4 and wait for that.
Jonathan
^ permalink raw reply
* Re: [PATCH 2/3] [v5 net-next] p54spi: convert to devicetree
From: Simon Horman @ 2026-05-11 16:12 UTC (permalink / raw)
To: arnd
Cc: 'Simon Horman', netdev, arnd, aaro.koskinen, andreas,
brgl, bcousson, davem, dmitry.torokhov, edumazet, balbi, kuba,
johannes, khilman, krzk+dt, linusw, pabeni, robh+dt, rogerq, tony,
linux-wireless, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap, krzk
In-Reply-To: <20260507212451.3333185-3-arnd@kernel.org>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
p54spi: convert to devicetree
This commit converts the Prism54 SPI driver from using hardcoded GPIO
module parameters to using the GPIO descriptor interface and device tree
probing.
> diff --git a/drivers/net/wireless/intersil/p54/p54spi.c b/drivers/net/wireless/intersil/p54/p54spi.c
> index 9d66dcae54e02..d18be25450285 100644
> --- a/drivers/net/wireless/intersil/p54/p54spi.c
> +++ b/drivers/net/wireless/intersil/p54/p54spi.c
[ ... ]
> @@ -30,19 +31,6 @@
> MODULE_FIRMWARE("3826.arm");
> MODULE_FIRMWARE("3826.eeprom");
>
> -/* gpios should be handled in board files and provided via platform data,
> - * but because it's currently impossible for p54spi to have a header file
> - * in include/linux, let's use module parameters for now
> - */
> -
> -static int p54spi_gpio_power = 97;
> -module_param(p54spi_gpio_power, int, 0444);
> -MODULE_PARM_DESC(p54spi_gpio_power, "gpio number for power line");
> -
> -static int p54spi_gpio_irq = 87;
> -module_param(p54spi_gpio_irq, int, 0444);
> -MODULE_PARM_DESC(p54spi_gpio_irq, "gpio number for irq line");
> -
> static void p54spi_spi_read(struct p54s_priv *priv, u8 address,
> void *buf, size_t len)
> {
Simon says: As a pre-existing issue I don't think we need to be concerned
about this in the scope of this patch-set. But it may
be a potential for follow-up.
This problem wasn't introduced by this patch, but I noticed a pre-existing
issue in the context here. Does the p54spi_spi_read() function perform an SPI
transfer using a stack-allocated buffer?
Looking at p54spi_spi_read(), the addr variable is allocated on the stack and
passed as a transfer buffer to spi_sync(). The SPI framework maps transfer
buffers for DMA. Passing a stack-allocated buffer is illegal, particularly with
CONFIG_VMAP_STACK enabled, because stack memory resides in vmalloc space and
cannot be safely DMA-mapped.
Could this cause memory corruption or a kernel panic during the transfer?
[ ... ]
> @@ -608,31 +596,20 @@ static int p54spi_probe(struct spi_device *spi)
> goto err_free;
> }
>
> - ret = gpio_request(p54spi_gpio_power, "p54spi power");
> - if (ret < 0) {
> - dev_err(&priv->spi->dev, "power GPIO request failed: %d", ret);
> + priv->gpio_powerdown = gpiod_get_optional(&spi->dev, "powerdown", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->gpio_powerdown)) {
> + ret = dev_err_probe(&priv->spi->dev, PTR_ERR(priv->gpio_powerdown),
> + "powerdown GPIO request failed\n");
> goto err_free;
> }
>
> - ret = gpio_request(p54spi_gpio_irq, "p54spi irq");
> - if (ret < 0) {
> - dev_err(&priv->spi->dev, "irq GPIO request failed: %d", ret);
> - goto err_free_gpio_power;
> - }
> -
> - gpio_direction_output(p54spi_gpio_power, 0);
> - gpio_direction_input(p54spi_gpio_irq);
> -
> - ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
> - p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi",
> - priv->spi);
> + ret = request_irq(spi->irq, p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi", priv->spi);
Simon says: This one seems more concerning in the context of this patch-set.
Is there missing validation for spi->irq before calling request_irq()?
If the device tree node lacks an interrupts property, the SPI core may set
spi->irq to 0 or a negative error code.
Passing this directly to request_irq() without validation can successfully
hijack a core system interrupt like the system timer on some architectures,
leading to system instability or deadlocks.
Should there be a check like if (spi->irq <= 0) to fail the probe gracefully?
> if (ret < 0) {
> dev_err(&priv->spi->dev, "request_irq() failed");
> - goto err_free_gpio_irq;
> + goto err_free_gpio_power;
> }
^ permalink raw reply
* Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch
From: Thomas Gleixner @ 2026-05-11 16:10 UTC (permalink / raw)
To: Arnd Bergmann, Arnd Bergmann, Will Deacon, Robin Murphy,
Joerg Roedel, Andrew Morton
Cc: linux-arm-kernel, iommu, linux-kernel, Sebastian Andrzej Siewior
In-Reply-To: <34af0db2-7a04-4119-925f-3aa3e3ecb683@app.fastmail.com>
On Mon, May 11 2026 at 11:46, Arnd Bergmann wrote:
> On Mon, May 11, 2026, at 09:18, Thomas Gleixner wrote:
>> I agree that the compiler does not know what __init means, but this
>> sucks as it leaves an unused copy of lookup_object_or_alloc() around
>> after init.
>>
>> What happens if you mark is_static_object() with 'noinline'?
>
> I've reproduced the issue with the release gcc-16.1.0 build,
> and tested marking is_static_object (along with
> dummy_tlb_add_page and dummy_tlb_flush from the other
> instance) as noinline.
>
> As expected, this avoids the problem as well.
I rather prefer that along with a comment explaining the 'noinline' oddity.
^ permalink raw reply
* [PATCH 3/3] usb: dwc3: xilinx: fix error handling in zynqmp init error paths
From: Radhey Shyam Pandey @ 2026-05-11 16:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey, stable
In-Reply-To: <20260511160814.2904882-1-radhey.shyam.pandey@amd.com>
Fix error handling and resource cleanup i.e remove invalid
phy_exit() after failed phy_init(), route failures through
proper cleanup paths and return 0 explicitly on success.
Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
Cc: stable@vger.kernel.org
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/usb/dwc3/dwc3-xilinx.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 94458b3da1a0..b832505e1b04 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -176,15 +176,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
ret = phy_init(priv_data->usb3_phy);
- if (ret < 0) {
- phy_exit(priv_data->usb3_phy);
+ if (ret < 0)
goto err;
- }
ret = reset_control_deassert(apbrst);
if (ret < 0) {
dev_err(dev, "Failed to release APB reset\n");
- goto err;
+ goto err_phy_exit;
}
if (priv_data->usb3_phy) {
@@ -200,26 +198,24 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
ret = reset_control_deassert(crst);
if (ret < 0) {
dev_err(dev, "Failed to release core reset\n");
- goto err;
+ goto err_phy_exit;
}
ret = reset_control_deassert(hibrst);
if (ret < 0) {
dev_err(dev, "Failed to release hibernation reset\n");
- goto err;
+ goto err_phy_exit;
}
ret = phy_power_on(priv_data->usb3_phy);
- if (ret < 0) {
- phy_exit(priv_data->usb3_phy);
- goto err;
- }
+ if (ret < 0)
+ goto err_phy_exit;
/* ulpi reset via gpio-modepin or gpio-framework driver */
reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(reset_gpio)) {
- return dev_err_probe(dev, PTR_ERR(reset_gpio),
- "Failed to request reset GPIO\n");
+ ret = PTR_ERR(reset_gpio);
+ goto err_phy_power_off;
}
if (reset_gpio) {
@@ -229,6 +225,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
dwc3_xlnx_set_coherency(priv_data, XLNX_USB_TRAFFIC_ROUTE_CONFIG);
+
+ return 0;
+
+err_phy_power_off:
+ phy_power_off(priv_data->usb3_phy);
+err_phy_exit:
+ phy_exit(priv_data->usb3_phy);
err:
return ret;
}
--
2.44.4
^ permalink raw reply related
* [PATCH 2/3] usb: dwc3: xilinx: use reset_control_reset() in versal init
From: Radhey Shyam Pandey @ 2026-05-11 16:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260511160814.2904882-1-radhey.shyam.pandey@amd.com>
Replace separate reset_control_assert() and reset_control_deassert() calls
with reset_control_reset(), which pulses the reset in one step. Report
failures with dev_err_probe() and a single message. No functional change.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/usb/dwc3/dwc3-xilinx.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index a3c7dc258c7d..94458b3da1a0 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -98,18 +98,10 @@ static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
dwc3_xlnx_mask_phy_rst(priv_data, false);
- /* Assert and De-assert reset */
- ret = reset_control_assert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to assert Reset\n");
- return ret;
- }
-
- ret = reset_control_deassert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to De-assert Reset\n");
- return ret;
- }
+ /* assert and deassert reset */
+ ret = reset_control_reset(crst);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to assert and deassert reset\n");
dwc3_xlnx_mask_phy_rst(priv_data, true);
dwc3_xlnx_set_coherency(priv_data, XLNX_USB2_TRAFFIC_ROUTE_CONFIG);
--
2.44.4
^ permalink raw reply related
* [PATCH 0/3] usb: dwc3: xilinx: minor fixes for dwc3-xilinx glue driver
From: Radhey Shyam Pandey @ 2026-05-11 16:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
Minor cleanups and a bug fix for the dwc3-xilinx glue driver:
- Fix a comment style violation (missing space before closing delimiter).
- Use reset_control_reset in versal init.
- Fix phy resource leak in zynqmp init error paths where phy_init() and
phy_power_on() resources were not properly released on failure.
Radhey Shyam Pandey (3):
usb: dwc3: xilinx: fix missing space before closing comment delimiter
usb: dwc3: xilinx: use reset_control_reset() in versal init
usb: dwc3: xilinx: fix error handling in zynqmp init error paths
drivers/usb/dwc3/dwc3-xilinx.c | 45 +++++++++++++++-------------------
1 file changed, 20 insertions(+), 25 deletions(-)
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
2.44.4
^ permalink raw reply
* [PATCH 1/3] usb: dwc3: xilinx: fix missing space before closing comment delimiter
From: Radhey Shyam Pandey @ 2026-05-11 16:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260511160814.2904882-1-radhey.shyam.pandey@amd.com>
Add missing space before '*/' in an inline comment to follow
the kernel coding style.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/usb/dwc3/dwc3-xilinx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index f41b0da5e89d..a3c7dc258c7d 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -196,7 +196,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
if (priv_data->usb3_phy) {
- /* Set PIPE Power Present signal in FPD Power Present Register*/
+ /* Set PIPE Power Present signal in FPD Power Present Register */
writel(FPD_POWER_PRSNT_OPTION, priv_data->regs + XLNX_USB_FPD_POWER_PRSNT);
/* Set the PIPE Clock Select bit in FPD PIPE Clock register */
writel(PIPE_CLK_SELECT, priv_data->regs + XLNX_USB_FPD_PIPE_CLK);
--
2.44.4
^ 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