* [PATCH v13 14/17] drm/exynos: exynos_dp: Apply analogix_dp_finish_probe()
From: Damon Ding @ 2026-04-09 7:19 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409071908.466294-1-damon.ding@rock-chips.com>
Apply analogix_dp_finish_probe() in order to move the panel/bridge
parsing from Exynos side to the Analogix side.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v4:
- Rename analogix_dp_find_panel_or_bridge() to
analogix_dp_finish_probe().
Changes in v7:
- Remove exynos_dp_legacy_bridge_init() and inline API
devm_drm_of_display_mode_bridge().
- If the panel or the next_bridge is parsed from DT, use ptr validity
to check whether to call component_add() directly at the end of
probing.
Changes in v9:
- Add Tested-by tag.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
drivers/gpu/drm/exynos/exynos_dp.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index b2597fafd73d..9f3d4d4c7352 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -158,9 +158,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *np;
struct exynos_dp_device *dp;
- struct drm_panel *panel;
- struct drm_bridge *bridge;
- int ret;
dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
@@ -187,30 +184,30 @@ static int exynos_dp_probe(struct platform_device *pdev)
goto out;
}
- ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, &panel, &bridge);
- if (ret == -ENODEV) {
+ if (of_get_display_timings(dev->of_node)) {
dp->plat_data.next_bridge = devm_drm_of_display_mode_bridge(dp->dev,
dp->dev->of_node,
DRM_MODE_CONNECTOR_eDP);
- ret = IS_ERR(dp->plat_data.next_bridge) ? PTR_ERR(dp->plat_data.next_bridge) : 0;
+ if (IS_ERR(dp->plat_data.next_bridge))
+ return PTR_ERR(dp->plat_data.next_bridge);
}
- if (ret)
- return ret;
/* The remote port can be either a panel or a bridge */
- dp->plat_data.panel = panel;
- dp->plat_data.next_bridge = bridge;
dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.attach = exynos_dp_bridge_attach;
+ dp->plat_data.ops = &exynos_dp_ops;
out:
dp->adp = analogix_dp_probe(dev, &dp->plat_data);
if (IS_ERR(dp->adp))
return PTR_ERR(dp->adp);
- return component_add(&pdev->dev, &exynos_dp_ops);
+ if (dp->plat_data.panel || dp->plat_data.next_bridge)
+ return component_add(&pdev->dev, &exynos_dp_ops);
+ else
+ return analogix_dp_finish_probe(dp->adp);
}
static void exynos_dp_remove(struct platform_device *pdev)
--
2.34.1
^ permalink raw reply related
* [PATCH v13 15/17] drm/bridge: analogix_dp: Attach the next bridge in analogix_dp_bridge_attach()
From: Damon Ding @ 2026-04-09 7:19 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409071908.466294-1-damon.ding@rock-chips.com>
Uniformly, move the next bridge attachment to the Analogix side
rather than scattered on Rockchip and Exynos sides. It can also
help get rid of the callback &analogix_dp_plat_data.attach() and
make codes more concise.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v6:
- Move the next bridge attachment to the Analogix side rather than
scattered on Rockchip and Exynos sides.
Changes in v9:
- Add Tested-by tag.
Changes in v11:
- Add Reviewed-by tag.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
.../drm/bridge/analogix/analogix_dp_core.c | 7 ++++---
drivers/gpu/drm/exynos/exynos_dp.c | 19 -------------------
include/drm/bridge/analogix_dp.h | 1 -
3 files changed, 4 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 17d078b836e3..3daf72aa643e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -930,10 +930,11 @@ static int analogix_dp_bridge_attach(struct drm_bridge *bridge,
return -EINVAL;
}
- if (dp->plat_data->attach) {
- ret = dp->plat_data->attach(dp->plat_data, bridge);
+ if (dp->plat_data->next_bridge) {
+ ret = drm_bridge_attach(dp->encoder, dp->plat_data->next_bridge, bridge,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret) {
- DRM_ERROR("Failed at platform attach func\n");
+ dev_err(dp->dev, "failed to attach following panel or bridge (%d)\n", ret);
return ret;
}
}
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index 9f3d4d4c7352..6884ea6d04eb 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -68,24 +68,6 @@ static int exynos_dp_poweroff(struct analogix_dp_plat_data *plat_data)
return exynos_dp_crtc_clock_enable(plat_data, false);
}
-static int exynos_dp_bridge_attach(struct analogix_dp_plat_data *plat_data,
- struct drm_bridge *bridge)
-{
- struct exynos_dp_device *dp = to_dp(plat_data);
- enum drm_bridge_attach_flags flags = 0;
- int ret;
-
- /* Pre-empt DP connector creation if there's a bridge */
- if (plat_data->next_bridge) {
- ret = drm_bridge_attach(&dp->encoder, plat_data->next_bridge, bridge,
- flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-
static void exynos_dp_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -196,7 +178,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
- dp->plat_data.attach = exynos_dp_bridge_attach;
dp->plat_data.ops = &exynos_dp_ops;
out:
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index bae969dec63a..854af692229b 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -34,7 +34,6 @@ struct analogix_dp_plat_data {
int (*power_on)(struct analogix_dp_plat_data *);
int (*power_off)(struct analogix_dp_plat_data *);
- int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *);
};
int analogix_dp_resume(struct analogix_dp_device *dp);
--
2.34.1
^ permalink raw reply related
* [PATCH v13 16/17] drm/bridge: analogix_dp: Remove bridge disabing and panel unpreparing in analogix_dp_unbind()
From: Damon Ding @ 2026-04-09 7:19 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409071908.466294-1-damon.ding@rock-chips.com>
The analogix_dp_unbind() should be balanced with analogix_dp_bind().
There are no bridge enabling and panel preparing in analogix_dp_bind(),
so it should be reasonable to remove the bridge disabing and panel
unpreparing in analogix_dp_unbind().
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v9:
- Add Tested-by tag.
Changes in v11:
- Add Reviewed-by tag.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3daf72aa643e..7d30e4184a80 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1526,10 +1526,6 @@ EXPORT_SYMBOL_GPL(analogix_dp_bind);
void analogix_dp_unbind(struct analogix_dp_device *dp)
{
- analogix_dp_bridge_disable(&dp->bridge);
-
- drm_panel_unprepare(dp->plat_data->panel);
-
drm_dp_aux_unregister(&dp->aux);
}
EXPORT_SYMBOL_GPL(analogix_dp_unbind);
--
2.34.1
^ permalink raw reply related
* [PATCH v13 17/17] drm/bridge: analogix_dp: Apply panel_bridge helper
From: Damon Ding @ 2026-04-09 7:19 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409071908.466294-1-damon.ding@rock-chips.com>
In order to unify the handling of the panel and bridge, apply
panel_bridge helpers for Analogix DP driver. With this patch, the
bridge support will also become available.
The following changes have ben made:
- Apply plane_bridge helper to wrap the panel as the bridge.
- Remove the explicit panel APIs calls, which can be replaced with
the automic bridge APIs calls wrapped by the panel.
- Remove the unnecessary analogix_dp_bridge_get_modes().
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v4:
- Rename the &analogix_dp_plat_data.bridge to
&analogix_dp_plat_data.next_bridge.
Changes in v5:
- Move panel_bridge addition a little forward.
- Move next_bridge attachment from Analogix side to Rockchip/Exynos
side.
Changes in v6
- Remove the unnecessary analogix_dp_bridge_get_modes().
- Not to set DRM_BRIDGE_OP_MODES if the next is a panel.
- Squash [PATCH v5 15/17]drm/bridge: analogix_dp: Remove panel
disabling and enabling in analogix_dp_set_bridge() into this
commit.
- Fix the &drm_bridge->ops to DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT.
Changes in v9:
- Add Tested-by tag.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
.../drm/bridge/analogix/analogix_dp_core.c | 41 +++++--------------
1 file changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7d30e4184a80..fb6b8aaa353b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -749,9 +749,6 @@ static int analogix_dp_commit(struct analogix_dp_device *dp)
{
int ret;
- /* Keep the panel disabled while we configure video */
- drm_panel_disable(dp->plat_data->panel);
-
ret = analogix_dp_train_link(dp);
if (ret) {
dev_err(dp->dev, "unable to do link train, ret=%d\n", ret);
@@ -771,9 +768,6 @@ static int analogix_dp_commit(struct analogix_dp_device *dp)
return ret;
}
- /* Safe to enable the panel now */
- drm_panel_enable(dp->plat_data->panel);
-
/* Check whether panel supports fast training */
ret = analogix_dp_fast_link_train_detection(dp);
if (ret)
@@ -858,17 +852,6 @@ static int analogix_dp_disable_psr(struct analogix_dp_device *dp)
return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
}
-static int analogix_dp_bridge_get_modes(struct drm_bridge *bridge, struct drm_connector *connector)
-{
- struct analogix_dp_device *dp = to_dp(bridge);
- int num_modes = 0;
-
- if (dp->plat_data->panel)
- num_modes += drm_panel_get_modes(dp->plat_data->panel, connector);
-
- return num_modes;
-}
-
static const struct drm_edid *analogix_dp_bridge_edid_read(struct drm_bridge *bridge,
struct drm_connector *connector)
{
@@ -909,7 +892,7 @@ analogix_dp_bridge_detect(struct drm_bridge *bridge, struct drm_connector *conne
struct analogix_dp_device *dp = to_dp(bridge);
enum drm_connector_status status = connector_status_disconnected;
- if (dp->plat_data->panel || dp->plat_data->next_bridge)
+ if (dp->plat_data->next_bridge)
return connector_status_connected;
if (!analogix_dp_detect_hpd(dp))
@@ -995,8 +978,6 @@ static void analogix_dp_bridge_atomic_pre_enable(struct drm_bridge *bridge,
/* Don't touch the panel if we're coming back from PSR */
if (old_crtc_state && old_crtc_state->self_refresh_active)
return;
-
- drm_panel_prepare(dp->plat_data->panel);
}
static int analogix_dp_set_bridge(struct analogix_dp_device *dp)
@@ -1168,16 +1149,12 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;
- drm_panel_disable(dp->plat_data->panel);
-
disable_irq(dp->irq);
analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
pm_runtime_put_sync(dp->dev);
- drm_panel_unprepare(dp->plat_data->panel);
-
dp->fast_train_enable = false;
dp->psr_supported = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1252,7 +1229,6 @@ static const struct drm_bridge_funcs analogix_dp_bridge_funcs = {
.atomic_post_disable = analogix_dp_bridge_atomic_post_disable,
.atomic_check = analogix_dp_bridge_atomic_check,
.attach = analogix_dp_bridge_attach,
- .get_modes = analogix_dp_bridge_get_modes,
.edid_read = analogix_dp_bridge_edid_read,
.detect = analogix_dp_bridge_detect,
};
@@ -1498,17 +1474,22 @@ int analogix_dp_bind(struct analogix_dp_device *dp, struct drm_device *drm_dev)
return ret;
}
- if (dp->plat_data->panel)
- bridge->ops = DRM_BRIDGE_OP_MODES | DRM_BRIDGE_OP_DETECT;
- else
- bridge->ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT;
-
+ bridge->ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT;
bridge->of_node = dp->dev->of_node;
bridge->type = DRM_MODE_CONNECTOR_eDP;
ret = devm_drm_bridge_add(dp->dev, &dp->bridge);
if (ret)
goto err_unregister_aux;
+ if (dp->plat_data->panel) {
+ dp->plat_data->next_bridge = devm_drm_panel_bridge_add(dp->dev,
+ dp->plat_data->panel);
+ if (IS_ERR(dp->plat_data->next_bridge)) {
+ ret = PTR_ERR(bridge);
+ goto err_unregister_aux;
+ }
+ }
+
ret = drm_bridge_attach(dp->encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret) {
DRM_ERROR("failed to create bridge (%d)\n", ret);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Krzysztof Kozlowski @ 2026-04-09 7:28 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <7f55458097ef651b4fc46650254afd3fa7b87348.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
> Introduce the device-tree bindings for I3C global registers found on
> AST2600 SoCs.
>
> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
> ---
> I wasn't sure if I should add newline at the end of the
> file or not so I took
> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
> as an example.
Answer is: you cannot have patch warnings.
Documentation/devicetree/bindings/i3c does not have patch warning, does
it?
> ---
> .../i3c/aspeed,ast2600-i3c-global.yaml | 55 +++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml
>
> diff --git a/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml
> new file mode 100644
> index 000000000000..edecc18796a9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i3c/aspeed,ast2600-i3c-global.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED AST2600 I3C Global Registers
> +
> +description: |
> + The AST2600 SoC provides a shared I3C global register block used by all
> + I3C controller instances. This block contains per-instance global
Why are you adding syscon to I3C controllers? Only I3C controllers go
to i3c directory.
syscons go soc.
> + configuration fields, including controller instance ID and SDA pull-up
> + configuration.
> + Each I3C controller references this syscon node through the
> + aspeed,global-regs property.
> +
> +maintainers:
> + - Dawid Glazik <dawid.glazik@linux.intel.com>
> +
> +allOf:
> + - $ref: /schemas/mfd/syscon-common.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - const: aspeed,ast2600-i3c-global
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
I do not see any differences against syscon.yaml binding. Why do you
need separate file? Look first how other platforms do it.
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
Drop entire node, not needed.
> +
> + i3c-global@0 {
> + compatible = "aspeed,ast2600-i3c-global", "syscon";
> + reg = <0x0 0x1000>;
> + resets = <&syscon ASPEED_RESET_I3C_DMA>;
> + };
> + };
> +...
> \ No newline at end of file
Patch warning.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Krzysztof Kozlowski @ 2026-04-09 7:30 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak, Jeremy Kerr
In-Reply-To: <51c4bdc02b45f67a0e32610a228091e137c135a6.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:34PM +0200, Dawid Glazik wrote:
> Add the i3c controller devices to the ast2600 g6 common dts. We add all
> 6 busses to the common g6 definition, but leave disabled through the
> status property, to be enabled per-platform.
>
> Originally-by: Jeremy Kerr <jk@codeconstruct.com.au>
Don't invent tags. This is not used outside of TIP.
> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
> ---
> v3:
> - add i3c aliases
> - rebase on top of latest tree and solve conflicts
> - as agreed with Jeremy off-list, he said I can take authorship of this going forward
> v2:
> - use inline bus representation, without the i3c: label
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 97 +++++++++++++++++++++++++
> 1 file changed, 97 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index f5641128614f..f986fcbed604 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -29,6 +29,12 @@ aliases {
> i2c13 = &i2c13;
> i2c14 = &i2c14;
> i2c15 = &i2c15;
> + i3c0 = &i3c0;
> + i3c1 = &i3c1;
> + i3c2 = &i3c2;
> + i3c3 = &i3c3;
> + i3c4 = &i3c4;
> + i3c5 = &i3c5;
Bus aliases are not properties of SoC DTSI.
> serial0 = &uart1;
> serial1 = &uart2;
> serial2 = &uart3;
> @@ -1066,6 +1072,97 @@ i2c15: i2c@800 {
> };
> };
>
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
> +
> + i3c_global: i3c-global@0 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Krzysztof Kozlowski @ 2026-04-09 7:30 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <20260409-beneficial-sociable-tamarin-dbcaeb@quoll>
On 09/04/2026 09:28, Krzysztof Kozlowski wrote:
> On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
>> Introduce the device-tree bindings for I3C global registers found on
>> AST2600 SoCs.
>>
>> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
>> ---
>> I wasn't sure if I should add newline at the end of the
>> file or not so I took
>> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
>> as an example.
>
> Answer is: you cannot have patch warnings.
>
> Documentation/devicetree/bindings/i3c does not have patch warning, does
> it?
And if you tested this code with standard tools, you would see that...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Krzysztof Kozlowski @ 2026-04-09 7:31 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak, Jeremy Kerr
In-Reply-To: <51c4bdc02b45f67a0e32610a228091e137c135a6.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:34PM +0200, Dawid Glazik wrote:
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
> +
> + i3c_global: i3c-global@0 {
> + compatible = "aspeed,ast2600-i3c-global", "syscon";
Also undocumented ABI. Apply this patch and run checkpatch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v14 00/10] arm64: entry: Convert to Generic Entry
From: Mark Rutland @ 2026-04-09 7:36 UTC (permalink / raw)
To: Jinjie Ruan
Cc: peterz, catalin.marinas, ldv, song, edumazet, will, mingo, kees,
thuth, ryan.roberts, arnd, anshuman.khandual, kevin.brodsky,
pengcan, broonie, mathieu.desnoyers, luto, linux-arm-kernel, wad,
linusw, oleg, linux-kernel, tglx, liqiang01, yeoreum.yun
In-Reply-To: <174e6d08-4922-f42f-2899-4c5b0df13469@huawei.com>
Hi Jinjie,
On Thu, Apr 09, 2026 at 02:29:04PM +0800, Jinjie Ruan wrote:
> On 2026/3/20 18:26, Jinjie Ruan wrote:
> > Currently, x86, Riscv, Loongarch use the Generic Entry which makes
> > maintainers' work easier and codes more elegant. arm64 has already
> > successfully switched to the Generic IRQ Entry in commit
> > b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
> > time to completely convert arm64 to Generic Entry.
> >
> > The goal is to bring arm64 in line with other architectures that already
> > use the generic entry infrastructure, reducing duplicated code and
> > making it easier to share future changes in entry/exit paths, such as
> > "Syscall User Dispatch" and RSEQ optimizations.
>
> Hi,
>
> Just a quick ping to see if this series is good to go. Do I need to
> provide a new version rebased on the latest arm64 for-next/generic-entry
> branches, or is the current version acceptable?
Sorry, this is on my list to review, but I've been busy fixing other
issues (e.g. the preemption issues from moving to generic irqentry), and
haven't yet had the time to go over this in detail.
This series might be fine as-is, but given that it's incredibly easy to
introduce subtle and hard-to-fix regressions to user ABI, I don't think
we can assume that it's safe until we've gone over it thoroughly.
For the moment, no need to resend. If you haven't received comments by
v7.1-rc1, please rebase and resend then.
Thanks,
Mark.
> > This patch set is rebased on arm64 for-next/core. This series contains
> > foundational updates for arm64. As suggested by Linus Walleij, these 10
> > patches are being submitted separately for inclusion in the arm64 tree.
> >
> > And the performance benchmarks results on qemu-kvm are below:
> >
> > perf bench syscall usec/op (-ve is improvement)
> >
> > | Syscall | Base | Generic Entry | change % |
> > | ------- | ----------- | ------------- | -------- |
> > | basic | 0.123997 | 0.120872 | -2.57 |
> > | execve | 512.1173 | 504.9966 | -1.52 |
> > | fork | 114.1144 | 113.2301 | -1.06 |
> > | getpgid | 0.120182 | 0.121245 | +0.9 |
> >
> > perf bench syscall ops/sec (+ve is improvement)
> >
> > | Syscall | Base | Generic Entry| change % |
> > | ------- | -------- | ------------ | -------- |
> > | basic | 8064712 | 8273212 | +2.48 |
> > | execve | 1952 | 1980 | +1.52 |
> > | fork | 8763 | 8832 | +1.06 |
> > | getpgid | 8320704 | 8247810 | -0.9 |
> >
> > Therefore, the syscall performance variation ranges from a 1% regression
> > to a 2.5% improvement.
> >
> > It was tested ok with following test cases on QEMU virt platform:
> > - Stress-ng CPU stress test.
> > - Hackbench stress test.
> > - "sud" selftest testcase.
> > - get_set_sud, get_syscall_info, set_syscall_info, peeksiginfo
> > in tools/testing/selftests/ptrace.
> > - breakpoint_test_arm64 in selftests/breakpoints.
> > - syscall-abi and ptrace in tools/testing/selftests/arm64/abi
> > - fp-ptrace, sve-ptrace, za-ptrace in selftests/arm64/fp.
> > - vdso_test_getrandom in tools/testing/selftests/vDSO
> > - Strace tests.
> > - slice_test for rseq optimizations.
> >
> > The test QEMU configuration is as follows:
> >
> > qemu-system-aarch64 \
> > -M virt \
> > -enable-kvm \
> > -cpu host \
> > -kernel Image \
> > -smp 8 \
> > -m 512m \
> > -nographic \
> > -no-reboot \
> > -device virtio-rng-pci \
> > -append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
> > earlycon preempt=voluntary irqchip.gicv3_pseudo_nmi=1 audit=1" \
> > -drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
> > -device virtio-blk-device,drive=hd0 \
> >
> > Changes in v14:
> > - Initialize ret = 0 in syscall_trace_enter().
> > - Split into two patch sets as Linus Walleij suggested, so this patch set
> > can be applied separately to the arm64 tree.
> > - Rebased on arm64 for-next/core branch.
> > - Collect Reviewed-by and Acked-by.
> > - Link to v13 resend: https://lore.kernel.org/all/20260317082020.737779-15-ruanjinjie@huawei.com/
> >
> > Changes in v13 resend:
> > - Fix exit_to_user_mode_prepare_legacy() issues.
> > - Also move TIF_SINGLESTEP to generic TIF infrastructure for loongarch.
> > - Use generic TIF bits for arm64 and moving TIF_SINGLESTEP to
> > generic TIF for related architectures separately.
> > - Refactor syscall_trace_enter/exit() to accept flags and Use
> > syscall_get_nr() helper separately.
> > - Tested with slice_test for rseq optimizations.
> > - Add acked-by.
> > - Link to v13: https://lore.kernel.org/all/20260313094738.3985794-1-ruanjinjie@huawei.com/
> >
> > Changes in v13:
> > - Rebased on v7.0-rc3, so drop the firt applied arm64 patch.
> > - Use generic TIF bits to enables RSEQ optimization.
> > - Update most of the commit message to make it more clear.
> > - Link to v12: https://lore.kernel.org/all/20260203133728.848283-1-ruanjinjie@huawei.com/
> >
> > Changes in v12:
> > - Rebased on "sched/core", so remove the four generic entry patches.
> > - Move "Expand secure_computing() in place" and
> > "Use syscall_get_arguments() helper" patch forward, which will group all
> > non-functional cleanups at the front.
> > - Adjust the explanation for moving rseq_syscall() before
> > audit_syscall_exit().
> > - Link to v11: https://lore.kernel.org/all/20260128031934.3906955-1-ruanjinjie@huawei.com/
> >
> > Changes in v11:
> > - Remove unused syscall in syscall_trace_enter().
> > - Update and provide a detailed explanation of the differences after
> > moving rseq_syscall() before audit_syscall_exit().
> > - Rebased on arm64 (for-next/entry), and remove the first applied 3 patchs.
> > - syscall_exit_to_user_mode_work() for arch reuse instead of adding
> > new syscall_exit_to_user_mode_work_prepare() helper.
> > - Link to v10: https://lore.kernel.org/all/20251222114737.1334364-1-ruanjinjie@huawei.com/
> >
> > Changes in v10:
> > - Rebased on v6.19-rc1, rename syscall_exit_to_user_mode_prepare() to
> > syscall_exit_to_user_mode_work_prepare() to avoid conflict.
> > - Also inline syscall_trace_enter().
> > - Support aarch64 for sud_benchmark.
> > - Update and correct the commit message.
> > - Add Reviewed-by.
> > - Link to v9: https://lore.kernel.org/all/20251204082123.2792067-1-ruanjinjie@huawei.com/
> >
> > Changes in v9:
> > - Move "Return early for ptrace_report_syscall_entry() error" patch ahead
> > to make it not introduce a regression.
> > - Not check _TIF_SECCOMP/SYSCALL_EMU for syscall_exit_work() in
> > a separate patch.
> > - Do not report_syscall_exit() for PTRACE_SYSEMU_SINGLESTEP in a separate
> > patch.
> > - Add two performance patch to improve the arm64 performance.
> > - Add Reviewed-by.
> > - Link to v8: https://lore.kernel.org/all/20251126071446.3234218-1-ruanjinjie@huawei.com/
> >
> > Changes in v8:
> > - Rename "report_syscall_enter()" to "report_syscall_entry()".
> > - Add ptrace_save_reg() to avoid duplication.
> > - Remove unused _TIF_WORK_MASK in a standalone patch.
> > - Align syscall_trace_enter() return value with the generic version.
> > - Use "scno" instead of regs->syscallno in el0_svc_common().
> > - Move rseq_syscall() ahead in a standalone patch to clarify it clearly.
> > - Rename "syscall_trace_exit()" to "syscall_exit_work()".
> > - Keep the goto in el0_svc_common().
> > - No argument was passed to __secure_computing() and check -1 not -1L.
> > - Remove "Add has_syscall_work() helper" patch.
> > - Move "Add syscall_exit_to_user_mode_prepare() helper" patch later.
> > - Add miss header for asm/entry-common.h.
> > - Update the implementation of arch_syscall_is_vdso_sigreturn().
> > - Add "ARCH_SYSCALL_WORK_EXIT" to be defined as "SECCOMP | SYSCALL_EMU"
> > to keep the behaviour unchanged.
> > - Add more testcases test.
> > - Add Reviewed-by.
> > - Update the commit message.
> > - Link to v7: https://lore.kernel.org/all/20251117133048.53182-1-ruanjinjie@huawei.com/
> >
> > Jinjie Ruan (10):
> > arm64/ptrace: Refactor syscall_trace_enter/exit() to accept flags
> > parameter
> > arm64/ptrace: Use syscall_get_nr() helper for syscall_trace_enter()
> > arm64/ptrace: Expand secure_computing() in place
> > arm64/ptrace: Use syscall_get_arguments() helper for audit
> > arm64: ptrace: Move rseq_syscall() before audit_syscall_exit()
> > arm64: syscall: Introduce syscall_exit_to_user_mode_work()
> > arm64/ptrace: Define and use _TIF_SYSCALL_EXIT_WORK
> > arm64/ptrace: Skip syscall exit reporting for PTRACE_SYSEMU_SINGLESTEP
> > arm64: entry: Convert to generic entry
> > arm64: Inline el0_svc_common()
> >
> > arch/arm64/Kconfig | 2 +-
> > arch/arm64/include/asm/entry-common.h | 76 +++++++++++++++++
> > arch/arm64/include/asm/syscall.h | 19 ++++-
> > arch/arm64/include/asm/thread_info.h | 16 +---
> > arch/arm64/kernel/debug-monitors.c | 7 ++
> > arch/arm64/kernel/entry-common.c | 25 ++++--
> > arch/arm64/kernel/ptrace.c | 115 --------------------------
> > arch/arm64/kernel/signal.c | 2 +-
> > arch/arm64/kernel/syscall.c | 29 ++-----
> > include/linux/irq-entry-common.h | 8 --
> > include/linux/rseq_entry.h | 18 ----
> > 11 files changed, 130 insertions(+), 187 deletions(-)
> >
^ permalink raw reply
* Re: [PATCH v14 2/4] asm-generic: Move TIF_SINGLESTEP to generic TIF bits
From: Mark Rutland @ 2026-04-09 7:42 UTC (permalink / raw)
To: Jinjie Ruan
Cc: catalin.marinas, will, chenhuacai, kernel, hca, gor, agordeev,
borntraeger, svens, oleg, tglx, mingo, bp, dave.hansen, hpa, arnd,
shuah, kevin.brodsky, yeoreum.yun, anshuman.khandual, thuth,
ryan.roberts, song, ziyao, linusw, schuster.simon, jremus, akpm,
mathieu.desnoyers, kmal, dvyukov, reddybalavignesh9979, x86,
linux-arm-kernel, linux-kernel, loongarch, linux-s390, linux-arch,
linux-kselftest
In-Reply-To: <20260320104222.1381274-3-ruanjinjie@huawei.com>
On Fri, Mar 20, 2026 at 06:42:20PM +0800, Jinjie Ruan wrote:
> Currently, x86, ARM64, s390, and LoongArch all define and use
> TIF_SINGLESTEP to track single-stepping state.
Do the architectures actually use the flag in the same way?
I'd expect that this is used subtly differently across those
architectures, and so isn't necessarily generic.
> Since this flag is shared across multiple major architectures and serves
> a common purpose in the generic entry/exit paths, move TIF_SINGLESTEP
> into the generic Thread Information Flags (TIF) infrastructure.
>
> This consolidation reduces architecture-specific boilerplate code and
> ensures consistency for generic features that rely on single-step
> state tracking.
Is it necessary to make this generic in order to move to generic irq
flags? I'd expect that generic code cannot make use of this due to the
different semantics across architectures, as noted abobve.
I think it's probably better to keep this architecture-specific for now,
where architectures can clearly define how they're using this bit.
Am I missing some reason why it's necessary to make this generic?
Mark.
> Cc: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/loongarch/include/asm/thread_info.h | 11 +++++------
> arch/s390/include/asm/thread_info.h | 7 +++----
> arch/x86/include/asm/thread_info.h | 6 ++----
> include/asm-generic/thread_info_tif.h | 5 +++++
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/arch/loongarch/include/asm/thread_info.h b/arch/loongarch/include/asm/thread_info.h
> index 4d7117fcdc78..a2ec87f18e1d 100644
> --- a/arch/loongarch/include/asm/thread_info.h
> +++ b/arch/loongarch/include/asm/thread_info.h
> @@ -70,6 +70,7 @@ register unsigned long current_stack_pointer __asm__("$sp");
> */
> #define HAVE_TIF_NEED_RESCHED_LAZY
> #define HAVE_TIF_RESTORE_SIGMASK
> +#define HAVE_TIF_SINGLESTEP
>
> #include <asm-generic/thread_info_tif.h>
>
> @@ -82,11 +83,10 @@ register unsigned long current_stack_pointer __asm__("$sp");
> #define TIF_32BIT_REGS 21 /* 32-bit general purpose registers */
> #define TIF_32BIT_ADDR 22 /* 32-bit address space */
> #define TIF_LOAD_WATCH 23 /* If set, load watch registers */
> -#define TIF_SINGLESTEP 24 /* Single Step */
> -#define TIF_LSX_CTX_LIVE 25 /* LSX context must be preserved */
> -#define TIF_LASX_CTX_LIVE 26 /* LASX context must be preserved */
> -#define TIF_USEDLBT 27 /* LBT was used by this task this quantum (SMP) */
> -#define TIF_LBT_CTX_LIVE 28 /* LBT context must be preserved */
> +#define TIF_LSX_CTX_LIVE 24 /* LSX context must be preserved */
> +#define TIF_LASX_CTX_LIVE 25 /* LASX context must be preserved */
> +#define TIF_USEDLBT 26 /* LBT was used by this task this quantum (SMP) */
> +#define TIF_LBT_CTX_LIVE 27 /* LBT context must be preserved */
>
> #define _TIF_NOHZ BIT(TIF_NOHZ)
> #define _TIF_USEDFPU BIT(TIF_USEDFPU)
> @@ -96,7 +96,6 @@ register unsigned long current_stack_pointer __asm__("$sp");
> #define _TIF_32BIT_REGS BIT(TIF_32BIT_REGS)
> #define _TIF_32BIT_ADDR BIT(TIF_32BIT_ADDR)
> #define _TIF_LOAD_WATCH BIT(TIF_LOAD_WATCH)
> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> #define _TIF_LSX_CTX_LIVE BIT(TIF_LSX_CTX_LIVE)
> #define _TIF_LASX_CTX_LIVE BIT(TIF_LASX_CTX_LIVE)
> #define _TIF_USEDLBT BIT(TIF_USEDLBT)
> diff --git a/arch/s390/include/asm/thread_info.h b/arch/s390/include/asm/thread_info.h
> index 1bcd42614e41..95be5258a422 100644
> --- a/arch/s390/include/asm/thread_info.h
> +++ b/arch/s390/include/asm/thread_info.h
> @@ -61,6 +61,7 @@ void arch_setup_new_exec(void);
> */
> #define HAVE_TIF_NEED_RESCHED_LAZY
> #define HAVE_TIF_RESTORE_SIGMASK
> +#define HAVE_TIF_SINGLESTEP
>
> #include <asm-generic/thread_info_tif.h>
>
> @@ -69,15 +70,13 @@ void arch_setup_new_exec(void);
> #define TIF_GUARDED_STORAGE 17 /* load guarded storage control block */
> #define TIF_ISOLATE_BP_GUEST 18 /* Run KVM guests with isolated BP */
> #define TIF_PER_TRAP 19 /* Need to handle PER trap on exit to usermode */
> -#define TIF_SINGLESTEP 21 /* This task is single stepped */
> -#define TIF_BLOCK_STEP 22 /* This task is block stepped */
> -#define TIF_UPROBE_SINGLESTEP 23 /* This task is uprobe single stepped */
> +#define TIF_BLOCK_STEP 20 /* This task is block stepped */
> +#define TIF_UPROBE_SINGLESTEP 21 /* This task is uprobe single stepped */
>
> #define _TIF_ASCE_PRIMARY BIT(TIF_ASCE_PRIMARY)
> #define _TIF_GUARDED_STORAGE BIT(TIF_GUARDED_STORAGE)
> #define _TIF_ISOLATE_BP_GUEST BIT(TIF_ISOLATE_BP_GUEST)
> #define _TIF_PER_TRAP BIT(TIF_PER_TRAP)
> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> #define _TIF_BLOCK_STEP BIT(TIF_BLOCK_STEP)
> #define _TIF_UPROBE_SINGLESTEP BIT(TIF_UPROBE_SINGLESTEP)
>
> diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
> index 0067684afb5b..f59072ba1473 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -98,9 +98,8 @@ struct thread_info {
> #define TIF_IO_BITMAP 22 /* uses I/O bitmap */
> #define TIF_SPEC_FORCE_UPDATE 23 /* Force speculation MSR update in context switch */
> #define TIF_FORCED_TF 24 /* true if TF in eflags artificially */
> -#define TIF_SINGLESTEP 25 /* reenable singlestep on user return*/
> -#define TIF_BLOCKSTEP 26 /* set when we want DEBUGCTLMSR_BTF */
> -#define TIF_ADDR32 27 /* 32-bit address space on 64 bits */
> +#define TIF_BLOCKSTEP 25 /* set when we want DEBUGCTLMSR_BTF */
> +#define TIF_ADDR32 26 /* 32-bit address space on 64 bits */
>
> #define _TIF_SSBD BIT(TIF_SSBD)
> #define _TIF_SPEC_IB BIT(TIF_SPEC_IB)
> @@ -112,7 +111,6 @@ struct thread_info {
> #define _TIF_SPEC_FORCE_UPDATE BIT(TIF_SPEC_FORCE_UPDATE)
> #define _TIF_FORCED_TF BIT(TIF_FORCED_TF)
> #define _TIF_BLOCKSTEP BIT(TIF_BLOCKSTEP)
> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> #define _TIF_ADDR32 BIT(TIF_ADDR32)
>
> /* flags to check in __switch_to() */
> diff --git a/include/asm-generic/thread_info_tif.h b/include/asm-generic/thread_info_tif.h
> index da1610a78f92..b277fe06aee3 100644
> --- a/include/asm-generic/thread_info_tif.h
> +++ b/include/asm-generic/thread_info_tif.h
> @@ -48,4 +48,9 @@
> #define TIF_RSEQ 11 // Run RSEQ fast path
> #define _TIF_RSEQ BIT(TIF_RSEQ)
>
> +#ifdef HAVE_TIF_SINGLESTEP
> +#define TIF_SINGLESTEP 12 /* reenable singlestep on user return*/
> +#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> +#endif
> +
> #endif /* _ASM_GENERIC_THREAD_INFO_TIF_H_ */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-09 7:43 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, tychang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai
In-Reply-To: <20260408025243.1155482-3-eleanor.lin@realtek.com>
On Wed, Apr 08, 2026 at 10:52:41AM +0800, Yu-Chun Lin wrote:
> +maintainers:
> + - Tzuyi Chang <tychang@realtek.com>
> +
> +description: |
> + GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
> + architecture that differs significantly from earlier RTD series controllers.
> + Each GPIO has dedicated registers for configuration (direction, input/output
> + values, debounce), and interrupt control supporting edge and level detection
> + modes.
> +
> +properties:
> + compatible:
> + enum:
> + - realtek,rtd1625-iso-gpio
> + - realtek,rtd1625-isom-gpio
> +
> + reg:
> + maxItems: 1
> + description: |
> + Memory region containing both interrupt control and GPIO
> + configuration registers in a contiguous address space.
> +
> + For realtek,rtd1625-iso-gpio:
> + - Base + 0x0 ~ 0xff: Interrupt control registers
> + - Base + 0x100 ~ 0x397: GPIO configuration registers
> +
> + For realtek,rtd1625-isom-gpio:
> + - Base + 0x0 ~ 0x1f: Interrupt control registers
> + - Base + 0x20 ~ 0x2f: GPIO configuration registers
Drop description, you are duplicating here DTS. Bindings do not need to
serve as reference manual for the device.
However when you state them like this and give them names, I have the
same concerns as last time - please consult your datasheet whether this
is really one address space.
With description dropped:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Stefano Radaelli @ 2026-04-09 7:48 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Dario Binacchi, Markus Niebel, Maud Spierings, Alexander Stein,
Ernest Van Hoecke, Josua Mayer, Francesco Dolcini, Primoz Fiser
In-Reply-To: <adcdWdTcVR2T2F5c@lizhi-Precision-Tower-5810>
Hi Frank!
On Wed, Apr 08, 2026 at 11:30:33PM -0400, Frank Li wrote:
>
> what' difference with imx93-var-som ? Can you reuse it?
>
The imx91-var-som is conceptually similar to imx93-var-som, and I used
it as a reference while preparing this DTS.
However, it cannot be directly reused as there are several hardware
differences between the two platforms, including SoC integration and
peripheral configuration (e.g. pinctrl, and available IPs).
So a separate description is required for imx91.
Best regards,
Stefano
^ permalink raw reply
* [PATCH v3 0/2] pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
From: Peng Fan (OSS) @ 2026-04-09 8:07 UTC (permalink / raw)
To: Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable
There is an errata for i.MX8MP VC8000E:
ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX
power up/down cycling.
Description: VC8000E reset de-assertion edge and AXI clock may have a
timing issue.
Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
de-asserted by HW)
This patchset is to fix the errata. More info could be found in each
patch commit.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v3:
- Separate power up notifier fix into patch 1
- Link to v2: https://lore.kernel.org/r/20260228-imx8mp-vc8000e-pm-v2-1-fd255a0d5958@nxp.com
Changes in v2:
- Add errata link in commit message
- Add comment for is_errata_err050531
- Link to v1: https://lore.kernel.org/r/20260128-imx8mp-vc8000e-pm-v1-1-6c171451c732@nxp.com
---
Peng Fan (2):
pmdomain: imx: Fix i.MX8MP power notifier
pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
drivers/pmdomain/imx/imx8m-blk-ctrl.c | 45 +++++++++++++++++++++++++++++++++--
1 file changed, 43 insertions(+), 2 deletions(-)
---
base-commit: b3ab9a7b9b32806b1b68c4fe7d5298702195eb3a
change-id: 20260128-imx8mp-vc8000e-pm-4278e6d48b54
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* [PATCH v3 1/2] pmdomain: imx: Fix i.MX8MP power notifier
From: Peng Fan (OSS) @ 2026-04-09 8:07 UTC (permalink / raw)
To: Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable
In-Reply-To: <20260409-imx8mp-vc8000e-pm-v3-0-3e023eaa245b@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Using imx8mm_vpu_power_notifier() for i.MX8MP is wrong, as it ungates
the VPU clocks to provide the ADB clock, which is necessary on i.MX8MM,
but on i.MX8MP there is a separate gate (bit 3) for the NoC. So add
imx8mp_vpu_power_notifier() for i.MX8MP.
Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl")
Cc: stable@vger.kernel.org
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/pmdomain/imx/imx8m-blk-ctrl.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
index 19e992d2ee3b845bc9382bcd494a5d96f9c6ac44..e13a47eeed75d7189aa15370a7bee4cceb05a1d6 100644
--- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
@@ -514,9 +514,34 @@ static const struct imx8m_blk_ctrl_domain_data imx8mp_vpu_blk_ctl_domain_data[]
},
};
+static int imx8mp_vpu_power_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct imx8m_blk_ctrl *bc = container_of(nb, struct imx8m_blk_ctrl,
+ power_nb);
+
+ if (action == GENPD_NOTIFY_ON) {
+ /*
+ * On power up we have no software backchannel to the GPC to
+ * wait for the ADB handshake to happen, so we just delay for a
+ * bit. On power down the GPC driver waits for the handshake.
+ */
+
+ udelay(5);
+
+ /* set "fuse" bits to enable the VPUs */
+ regmap_set_bits(bc->regmap, 0x8, 0xffffffff);
+ regmap_set_bits(bc->regmap, 0xc, 0xffffffff);
+ regmap_set_bits(bc->regmap, 0x10, 0xffffffff);
+ regmap_set_bits(bc->regmap, 0x14, 0xffffffff);
+ }
+
+ return NOTIFY_OK;
+}
+
static const struct imx8m_blk_ctrl_data imx8mp_vpu_blk_ctl_dev_data = {
.max_reg = 0x18,
- .power_notifier_fn = imx8mm_vpu_power_notifier,
+ .power_notifier_fn = imx8mp_vpu_power_notifier,
.domains = imx8mp_vpu_blk_ctl_domain_data,
.num_domains = ARRAY_SIZE(imx8mp_vpu_blk_ctl_domain_data),
};
--
2.37.1
^ permalink raw reply related
* [PATCH v3 2/2] pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
From: Peng Fan (OSS) @ 2026-04-09 8:07 UTC (permalink / raw)
To: Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable
In-Reply-To: <20260409-imx8mp-vc8000e-pm-v3-0-3e023eaa245b@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Per errata[1]:
ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX
power up/down cycling.
Description: VC8000E reset de-assertion edge and AXI clock may have a
timing issue.
Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
de-asserted by HW)
Add a bool variable is_errata_err050531 in
'struct imx8m_blk_ctrl_domain_data' to represent whether the workaround
is needed. If is_errata_err050531 is true, first clear the clk before
powering up gpc, then enable the clk after powering up gpc.
[1] https://www.nxp.com/webapp/Download?colCode=IMX8MP_1P33A
Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl")
Cc: stable@vger.kernel.org
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/pmdomain/imx/imx8m-blk-ctrl.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
index e13a47eeed75d7189aa15370a7bee4cceb05a1d6..1cd0a22ce3e533358dd7449da9989162b36c5fe6 100644
--- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
@@ -54,6 +54,15 @@ struct imx8m_blk_ctrl_domain_data {
* register.
*/
u32 mipi_phy_rst_mask;
+
+ /*
+ * VC8000E reset de-assertion edge and AXI clock may have a timing issue.
+ * Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
+ * both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
+ * VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
+ * de-asserted by HW)
+ */
+ bool is_errata_err050531;
};
#define DOMAIN_MAX_CLKS 4
@@ -108,7 +117,11 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd)
dev_err(bc->dev, "failed to enable clocks\n");
goto bus_put;
}
- regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
+
+ if (data->is_errata_err050531)
+ regmap_clear_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
+ else
+ regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
/* power up upstream GPC domain */
ret = pm_runtime_get_sync(domain->power_dev);
@@ -117,6 +130,9 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd)
goto clk_disable;
}
+ if (data->is_errata_err050531)
+ regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
+
/* wait for reset to propagate */
udelay(5);
--
2.37.1
^ permalink raw reply related
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-04-09 8:05 UTC (permalink / raw)
To: Stefan Wahren
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Srinivas Kandagatla, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <90f54202-6eb6-4c44-b029-a4e0dafad861@gmx.net>
On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
> > Hi Stefan,
> >
> > thanks for the review.
> > > Is there any reason, why we cannot register this driver in
> > > rpi_firmware_probe() like hwmon and clk driver?
> > >
> > > I like to avoid the complete dt-binding from patch 1.
> > The private OTP registers are not available on all Raspberries. Afaik
> > only on 4 and 5. So I think these registers must be described through
> > the device tree. Therefore the bindings are needed.
> This binding doesn't represent some kind of hardware, it's just some
> firmware interface. A proper DT binding would describe the MMIO address
> range for OTP access.
I think it does represent real hardware. Although it is hidden through the
firmware. Not all hardware must be MMIO addresses.
The only driver that does not have a DT node is the hwmon driver. All
other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
binding. Looking at the comment in rpi_register_clk_driver this
seems to be some legacy behaviour for older DTs for the clock driver.
> If you need some distinction between the Raspberry Pi generations there are
> firmware tags to do this.
So what is your suggestion? What tags do you mean?
I don't understand why you want to avoid the dt-binding. What is the
problem with dt-bindings?
What is the benefit of registering the driver in rpi_firmware_probe?
Imho describing this in the DT is the more natural way to do this. E.g.
if in the future there is a raspberry pi with a 64Byte otp it could easily
be supported by adding a devicetree property and add it to the driver.
Regards
Gregor
^ permalink raw reply
* Re: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Vladimir Oltean @ 2026-04-09 8:07 UTC (permalink / raw)
To: Wei Fang
Cc: Jakub Kicinski, Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <AM8PR04MB72840DBFC7F3FD578DFF6AF8885BA@AM8PR04MB7284.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 11:59:24AM +0300, Wei Fang wrote:
> > > +static int netc_init_switch_id(struct netc_switch *priv)
> > > +{
> > > + struct netc_switch_regs *regs = &priv->regs;
> > > + struct dsa_switch *ds = priv->ds;
> > > +
> > > + /* The value of 0 is reserved for the VEPA switch and cannot
> > > + * be used.
> > > + */
> > > + if (ds->index > SWCR_SWID || !ds->index) {
> > > + dev_err(priv->dev, "Switch index %d out of range\n",
> > > + ds->index);
> > > + return -ERANGE;
> > > + }
> >
> > Does this check cause the probe to fail unconditionally for standard
> > single-switch topologies?
> >
> > The DSA core typically assigns ds->index = 0 by default for the first switch.
> > Because !ds->index evaluates to true for index 0, this setup function will
> > always fail unless the dsa,member property is explicitly overridden in the
> > device tree.
>
> As I mentioned in another mail, we added the 'dsa,member' property to the
> netc switch DT-binding doc, specifying that the 'member' (switch index) value
> cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> >
> > Could the driver translate the hardware ID internally, for example by writing
> > ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> > restriction onto the software DSA index?
>
> The current approach is based on Vladimir's suggestion. I need to confirm with
> Vladimir which approach is better.
>
> Hi Vladimir,
>
> What are your thoughts on this suggestion? Is this approach better?
I maintain it is preferable/simpler the way you are doing it, with a 1:1 mapping.
The LLM's concern would be more valid if the switch were discrete and every
board DTS author would have to remember to place the dsa,member property.
But the switch OF node will live in an SoC dtsi.
Maybe you could put something along these lines in the commit message,
hopefully the LLM will pick it up and stop complaining.
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
From: Krzysztof Kozlowski @ 2026-04-09 8:10 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland, linux-arm-kernel,
iommu, devicetree, linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-1-d75dac96e828@nxp.com>
On Wed, Apr 08, 2026 at 03:51:15PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> The Arm SMMU v3 specification defines an optional PMCG (Performance
"optional" in a meaning some SMMUv3 implementations do not have it?
> Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
> with TCU Performance Monitor Counter Group (PMCG) registers starting at
> offset 0x02000 in page 0. So PMCG could be described as a child node of the
> SMMU in Devicetree.
>
> Add a patternProperties entry to the arm,smmu-v3 binding to allow child
> nodes matching "pmu@<addr>" and reference the existing
> arm,smmu-v3-pmcg.yaml schema.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -50,6 +50,10 @@ properties:
> - cmdq-sync # CMD_SYNC complete
> - priq # PRI Queue not empty
>
> + '#address-cells': true
Instead enum [1, 2]
> + '#size-cells': true
Same here
> + ranges: true
I guess only one mapping is allowed so:
maxItems: 1
> +
> '#iommu-cells':
> const: 1
>
> @@ -83,6 +87,12 @@ properties:
> register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
> doesn't support SMMU page1 register space.
>
> +patternProperties:
> + '^pmu@[0-9a-f]+$':
> + type: object
> + $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
> + unevaluatedProperties: false
Please add another example with 4-space indentation.
> +
> allOf:
> - if:
> not:
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
From: Krzysztof Kozlowski @ 2026-04-09 8:13 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-1-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:15AM +0200, Gregor Herburger wrote:
> The firmware running on the Raspberry Pi VideoCore can be used to access
> OTP registers. There are two OTP regions (private and customer). Add a
> binding for these.
A nit, subject: drop second/last, redundant "a binding for the". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec9..975c8927d75b 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -137,6 +137,20 @@ required:
> - compatible
> - mboxes
>
> +patternProperties:
> + "^otp-(customer|private)$":
Not a pattern but just "otp".
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + enum:
> + - raspberrypi,firmware-otp-customer
> + - raspberrypi,firmware-otp-private
I don't understand why having OTP regions is not deducible from
top-level compatible. I also do not get why do you need per OTP
compatible.
There are no resources here, so standard review would be "no" and you
need strong justification in terms of DT.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Krzysztof Kozlowski @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-3-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> The Raspberry Pi 5 has two OTP registers (private and customer), add these
> to the devicetree.
So this sentence confirms my question on bindings - your device
raspberrypi,bcm2835-firmware has these, thus you do not need these child
nodes at all. Neither compatibles.
Drop entire DTS and binding patches.
See also writing-bindings and DTS101 why we do not allow this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: marvell: armada-37xx: USB3 PHY cleanup
From: Gregory CLEMENT @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gabor Juhos, Andrew Lunn, Sebastian Hesselbarth, Robert Marko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Stanley Chang
Cc: linux-arm-kernel, devicetree, linux-kernel, Gabor Juhos
In-Reply-To: <20260330-armada-37xx-usb3-phy-cleanup-v1-0-34d77f1a1784@gmail.com>
Gabor Juhos <j4g8y7@gmail.com> writes:
> There are two small patches in the series. The first helps to avoid
> triggering a bug in the USB core code, whereas the second one is a
> small cleanup to align PHY definitions of the USB3 node with other
> platforms.
>
> Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
> ---
> Gabor Juhos (2):
> arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
> arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
>
> arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 2 +-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> base-commit: 2ff6cc999a04bcb094b8cbba68a9251f03a5c876
> change-id: 20260330-armada-37xx-usb3-phy-cleanup-922a5472794a
>
> Best regards,
> --
> Gabor Juhos <j4g8y7@gmail.com>
>
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] arm: artpec: Remove unnecessary semicolons in artpec6_init_machine()
From: Jesper Nilsson @ 2026-04-09 8:15 UTC (permalink / raw)
To: Nobuhiro Iwamatsu
Cc: jesper.nilsson, lars.persson, linux-arm-kernel, linux-arm-kernel,
linux-kernel
In-Reply-To: <1775710886-13833-1-git-send-email-nobuhiro.iwamatsu.x90@mail.toshiba>
On Thu, Apr 09, 2026 at 02:01:26PM +0900, Nobuhiro Iwamatsu wrote
> Remove unnecessary semicolons in artpec6_init_machine().
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Krzysztof Kozlowski @ 2026-04-09 8:17 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-2-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:16AM +0200, Gregor Herburger wrote:
> Raspberry Pis have OTP registers which can be accessed through the
> videocore firmware. Add a nvmem driver to support these OTP registers.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> drivers/nvmem/Kconfig | 12 +++
> drivers/nvmem/Makefile | 1 +
> drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
> include/soc/bcm2835/raspberrypi-firmware.h | 2 +
> 4 files changed, 174 insertions(+)
>
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 74ddbd0f79b0..892d05fe67be 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
> This driver can also be built as a module. If so, the module
> will be called nvmem_qoriq_efuse.
>
> +config NVMEM_RASPBERRYPI_OTP
> + tristate "Raspberry Pi OTP support"
> + # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> + # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
Drop comment and use standard rules for multiple modules.
https://lwn.net/Articles/944368/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
From: Linus Walleij @ 2026-04-09 8:27 UTC (permalink / raw)
To: Janne Grunau
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Neal Gompa, Wim Van Sebroeck, Guenter Roeck,
Mark Kettenis, Andi Shyti, Uwe Kleine-König,
Sasha Finkelstein, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-watchdog, linux-gpio, linux-i2c,
linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-5-5842e1e393a8@jannau.net>
On Fri, Mar 20, 2026 at 1:23 PM Janne Grunau <j@jannau.net> wrote:
> The pin controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-pinctrl" as SoC specific
> compatible under "apple,t8103-pinctrl" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
This patch applied to the pinctrl tree for v7.1.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v7.0 (#1)
From: Gregory CLEMENT @ 2026-04-09 8:28 UTC (permalink / raw)
To: Arnd Bergmann, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
Hi,
Here is the first pull request for fixes for mvebu for v7.0.
Gregory
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-fixes-7.0-1
for you to fetch changes up to edb7efa767da8bb82d724b85178be251ec4e060e:
dt-bindings: arm64: add Marvell 7k COMe boards (2026-03-13 16:41:11 +0100)
----------------------------------------------------------------
mvebu fixes for 7.0 (part 1)
A new device tree has been merged without a binding, which triggered
warnings during dtb_checks. The commit in this pull request fixes this
issue, enabling easier detection of new problems in device trees by
reducing the number of false warnings.
----------------------------------------------------------------
Elad Nachman (1):
dt-bindings: arm64: add Marvell 7k COMe boards
.../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox