* Re: [PATCH net-next v4 00/13] net: lan966x: add support for PCIe FDMA
From: Daniel Machon @ 2026-05-12 9:56 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260511192018.49dfcd7b@kernel.org>
> On Fri, 8 May 2026 09:35:24 +0200 Daniel Machon wrote:
> > When lan966x operates as a PCIe endpoint, the driver currently uses
> > register-based I/O for frame injection and extraction. This approach is
> > functional but slow, topping out at around 33 Mbps on an Intel x86 host
> > with a lan966x PCIe card.
>
> Looks like sashiko-bot responded but only CCed bpf@
> Please let us know if all the issues are false positives,
> I'm going to assume for now that at least one of the issues
> is real :)
I ran through all the issues from sashiko-gemini (sashiko-nipa only reported low
severity issues).
Most of them are false-positives, some are pre-existing and some are purely
theoretical. I have experimented a little with fixing some of the theoretical,
but subsequent local sashiko runs seem to just find new ones indefinitely ;)
IMHO, like Paolo commented on v3, I think these can safely be postponed to
future follow-ups, if need be.
Let me know what you think.
/Daniel
^ permalink raw reply
* [PATCH v4 03/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP0 node with
corresponding clock-name "hclk". This clock is necessary for the
eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: dc79d3d5e7c7 ("arm64: dts: rockchip: Add eDP0 node for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index 4fb8888c281c..24a5ccbac08c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -1712,8 +1712,8 @@ hdmi0_out: port@1 {
edp0: edp@fdec0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfdec0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy0>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* [PATCH v4 02/10] dt-bindings: display: rockchip: analogix-dp: Add per-clock descriptions
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Supplement dedicated description for each clock in the clocks
property, clarifying the function of each clock input for the
Analogix DP controller binding.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d2bc8636b626..0651853a7a5d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -19,7 +19,10 @@ properties:
clocks:
minItems: 2
- maxItems: 3
+ items:
+ - description: Reference clock
+ - description: APB bus clock
+ - description: GRF or AHB bus clock
clock-names:
minItems: 2
--
2.34.1
^ permalink raw reply related
* [PATCH v4 00/10] Add eDP support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
Patch 1-5 are to add missing clock "hclk" for RK3588 eDP nodes.
Patch 6-7 are to add the RK3576 eDP node.
Patch 8~10 are to support the RK3576 Analogix DP controller.
This series is followed by the [0] series.
[0] https://lore.kernel.org/all/20260409065301.446670-1-damon.ding@rock-chips.com/
Damon Ding (10):
dt-bindings: display: rockchip: analogix-dp: Allow hclk as third clock
dt-bindings: display: rockchip: analogix-dp: Add per-clock
descriptions
arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
drm/rockchip: analogix_dp: Enable hclk for RK3588
dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
arm64: dts: rockchip: Add eDP node for RK3576
drm/bridge: analogix_dp: Rename and simplify is_rockchip()
drm/bridge: analogix_dp: Add support for RK3576
drm/rockchip: analogix_dp: Add support for RK3576
.../rockchip/rockchip,analogix-dp.yaml | 11 ++++++--
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 +++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 +--
.../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 4 +--
.../drm/bridge/analogix/analogix_dp_core.c | 3 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++++++------
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 15 ++++++++++
include/drm/bridge/analogix_dp.h | 13 +++++++--
8 files changed, 78 insertions(+), 18 deletions(-)
---
Changes in v2:
- Split out separate patches to add the "hclk" clock reference.
- Split out separate patches to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add a patch to expand descriptions for clocks of the eDP node.
- Add Reviewed-by tag.
Changes in v4:
- Modify commit msg.
--
2.34.1
^ permalink raw reply
* [PATCH v4 01/10] dt-bindings: display: rockchip: analogix-dp: Allow hclk as third clock
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
RK3588 eDP controller requires HCLK_VO1 (video output bus clock)
to access the VO1 GRF registers and enable the video datapath.
Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
phandle reference, which allowed the eDP to work without explicitly
managing the hclk_vo1 clock. However, this is not safe or explicit.
To align with other display controllers (HDMI) on RK3588 and make
the clock requirement explicit, expand clock-names to support either
"grf" (for older SoCs) or "hclk" (for RK3588) as the third clock.
This makes the clock dependency clear and removes reliance on implicit
clock enablement from GRF phandle.
Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d99b23b88cc5..d2bc8636b626 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -26,7 +26,9 @@ properties:
items:
- const: dp
- const: pclk
- - const: grf
+ - enum:
+ - grf
+ - hclk
power-domains:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v4 06/10] dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
RK3576 integrates an eDP TX controller compatible with the existing
RK3588 hardware design, reuse the same binding configuration directly.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v2:
- Split out a separate patch to add the "hclk" clock reference.
Chanegs in v4:
- Modify the commit msg.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index 0651853a7a5d..7568044a5b2f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -15,6 +15,7 @@ properties:
enum:
- rockchip,rk3288-dp
- rockchip,rk3399-edp
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
clocks:
@@ -70,6 +71,7 @@ allOf:
compatible:
contains:
enum:
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
then:
properties:
--
2.34.1
^ permalink raw reply related
* [PATCH v4 05/10] drm/rockchip: analogix_dp: Enable hclk for RK3588
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Acquire and enable the HCLK_VO1 bus clock explicitly for RK3588
eDP controller to guarantee register and datapath access.
The clock was previously enabled implicitly via rockchip,vo-grf
phandle reference, which relies on side effect and is fragile.
Fetch optional "hclk" clock in driver to align with updated device
tree binding and keep consistent with hardware clock dependency.
Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 41ff44eaf44d..a864bcf8200e 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -311,6 +311,7 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
{
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
+ struct clk *clk;
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf))
@@ -327,6 +328,11 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
return dev_err_probe(dev, PTR_ERR(dp->pclk),
"failed to get pclk property\n");
+ clk = devm_clk_get_optional_enabled(dev, "hclk");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get hclk property\n");
+
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst))
return dev_err_probe(dev, PTR_ERR(dp->rst),
--
2.34.1
^ permalink raw reply related
* [PATCH v4 08/10] drm/bridge: analogix_dp: Rename and simplify is_rockchip()
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Rename inline helper is_rockchip() to analogix_dp_is_rockchip()
to follow driver namespace convention consistently across code.
Replace chained equality comparisons with switch-case layout
to improve readability and simplify adding new SoC entries later.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Suggested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
.../gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 +++++++++---------
include/drm/bridge/analogix_dp.h | 11 +++++++++--
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3e46350170d4..d45c81c1d77a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -870,7 +870,7 @@ static int analogix_dp_bridge_atomic_check(struct drm_bridge *bridge,
struct drm_display_info *di = &conn_state->connector->display_info;
u32 mask = BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) | BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422);
- if (is_rockchip(dp->plat_data->dev_type)) {
+ if (analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
if ((di->color_formats & mask)) {
DRM_DEBUG_KMS("Swapping display color format from YUV to RGB\n");
di->color_formats &= ~mask;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 38fd8d5014d2..6207ded7ffd5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -72,7 +72,7 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg = REF_CLK_24M;
if (dp->plat_data->dev_type == RK3288_DP)
reg ^= REF_CLK_MASK;
@@ -123,7 +123,7 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
SW_FUNC_EN_N;
else
@@ -233,7 +233,7 @@ void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
u32 mask = DP_PLL_PD;
u32 pd_addr = ANALOGIX_DP_PLL_CTL;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
pd_addr = ANALOGIX_DP_PD;
mask = RK_PLL_PD;
}
@@ -254,12 +254,12 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
u32 mask;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = RK_AUX_PD;
else
mask = AUX_PD;
@@ -317,7 +317,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
* to power off everything instead of DP_PHY_PD in
* Rockchip
*/
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = DP_INC_BG;
else
mask = DP_PHY_PD;
@@ -329,7 +329,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
reg &= ~mask;
writel(reg, dp->reg_base + phy_pd_addr);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
usleep_range(10, 15);
break;
case POWER_ALL:
@@ -465,7 +465,7 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
analogix_dp_reset_aux(dp);
/* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = 0;
else
reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3);
@@ -837,7 +837,7 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
u32 reg;
reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
} else {
reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 854af692229b..7b670dd769e9 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -19,9 +19,16 @@ enum analogix_dp_devtype {
RK3588_EDP,
};
-static inline bool is_rockchip(enum analogix_dp_devtype type)
+static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
{
- return type == RK3288_DP || type == RK3399_EDP || type == RK3588_EDP;
+ switch (type) {
+ case RK3288_DP:
+ case RK3399_EDP:
+ case RK3588_EDP:
+ return true;
+ default:
+ return false;
+ }
}
struct analogix_dp_plat_data {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 09/10] drm/bridge: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add RK3576_EDP device type entry and extend Rockchip check
to match existing hardware capabilities shared with RK3588.
Set identical maximum link rate and lane count parameters
for RK3576 eDP controller to reuse existing RK3588 config.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
include/drm/bridge/analogix_dp.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d45c81c1d77a..0ff1b4a70e70 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1249,6 +1249,7 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
video_info->max_link_rate = 0x0A;
video_info->max_lane_count = 0x04;
break;
+ case RK3576_EDP:
case RK3588_EDP:
video_info->max_link_rate = 0x14;
video_info->max_lane_count = 0x04;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 7b670dd769e9..0e0b87abee59 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -16,6 +16,7 @@ enum analogix_dp_devtype {
EXYNOS_DP,
RK3288_DP,
RK3399_EDP,
+ RK3576_EDP,
RK3588_EDP,
};
@@ -24,6 +25,7 @@ static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
switch (type) {
case RK3288_DP:
case RK3399_EDP:
+ case RK3576_EDP:
case RK3588_EDP:
return true;
default:
--
2.34.1
^ permalink raw reply related
* [PATCH v4 10/10] drm/rockchip: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
RK3576 integrates Analogix eDP 1.3 TX and Samsung combo PHY
hardware blocks that fully match the proven RK3588 design.
Add dedicated chip data table and device tree matching entry
to bring up basic eDP functionality for the RK3576 platform.
Support is limited to RGB output up to 4K@60Hz for now; audio,
PSR and other advanced eDP 1.3 features remain unvalidated.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- Split out a separate patch to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index a864bcf8200e..75706a2fdba8 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -522,6 +522,14 @@ static const struct rockchip_dp_chip_data rk3288_dp[] = {
{ /* sentinel */ }
};
+static const struct rockchip_dp_chip_data rk3576_edp[] = {
+ {
+ .chip_type = RK3576_EDP,
+ .reg = 0x27dc0000,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dp_chip_data rk3588_edp[] = {
{
.edp_mode = GRF_REG_FIELD(0x0000, 0, 0),
@@ -539,6 +547,7 @@ static const struct rockchip_dp_chip_data rk3588_edp[] = {
static const struct of_device_id rockchip_dp_dt_ids[] = {
{.compatible = "rockchip,rk3288-dp", .data = &rk3288_dp },
{.compatible = "rockchip,rk3399-edp", .data = &rk3399_edp },
+ {.compatible = "rockchip,rk3576-edp", .data = &rk3576_edp },
{.compatible = "rockchip,rk3588-edp", .data = &rk3588_edp },
{}
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Joonwon Kang @ 2026-05-12 9:57 UTC (permalink / raw)
To: jgg, robin.murphy
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan, iommu,
jacob.jun.pan, joonwonkang, joro, jpb, kees, kevin.tian,
linux-arm-kernel, linux-kernel, nicolinc, praan, smostafa, will
In-Reply-To: <20260511132128.GM9285@ziepe.ca>
Hi Jason and Robin, thanks a lot for sharing your insights! Could you help
to answer the further questions below? or just let me know if it is better
to use other channels for them like ARM support.
> On Mon, May 11, 2026 at 01:39:06PM +0100, Robin Murphy wrote:
> > On 2026-05-09 6:10 pm, Jason Gunthorpe wrote:
> > > On Thu, May 07, 2026 at 09:58:51AM +0000, Joonwon Kang wrote:
> > >
> > > > By "similar instruction" on ARM, I guess you mean ST64BV0, which fetches
> > > > the bottom 32 bits data from ACCDATA_EL1. Please let me know if you meant
> > > > others as it will matter. If ST64BV0 is supported on ARM, however, it
> > > > would mean that ST64B and ST64BV are also supported already according to
> > > > the ID_AA64ISAR1_EL1's LS64 field. The latter 2 instructions are just to
> > > > atomically store whatever user wants to a memory location without
> > > > referring to ACCDATA_EL1 and all the 3 instructions can be run at EL0. So,
> > > > the userspace driver would have enough capability to designate arbitrary
> > > > PASID as it wants via the latter 2 instructions when communicating with
> > > > multiple devices.
> > >
> > > IDK exactly what ARM did. IIRC on Intel ENQCMD forms a special
> > > non-posted write TLP and the device can tell the TLP came from ENQCMD
> > > and so it trusts the encoded PASID. ARM has to have done the same
> > > thing - allowing anyone to forge the PASID by using a different
> > > instruction misses the point of the Intel design.
> >
> > Yes, ACCDATA_EL1 is a privileged register neither writeable nor readable by
> > userspace[1], so it should be functionally equivalent from an SVA point of
> > view.
>
> There is a bit more going on though, I think that is what Joonwon is
> mentioning by asking about ST64B and ST64BV. I *think* the answer is:
>
> - ST64B uses a posted write
> - ST64BV can be restricted so EL0 cannot execute it, it uses a
> non-posted write (AI tells me via EnASR)
> - ST64BV0 can be used by EL0, always uses a non-posted write, and always
> uses ACCDATA_EL1
>
> Which is similar to Intel.
Ah, I missed that ST64BV is currently being trapped to EL1 while ST64B is
not [1]. However, I am not sure if the trap is to disallow EL0 to use it.
Can it be instead to pass the response value of the non-posted write to
EL0 while using the EL0-given PASID as-is? If so, I believe EL0 still can
specify arbitrary PASID as it wants via ST64BV.
Since I guess ST64B* instructions are to serve generic purposes not only
for communication with accelerators with SIOV but also with any memory
location or device without SIOV, I am not sure if it is always okay to
make those instructions work the way Jason mentioned.
> The device only processes the PASID from a non-posted write,
>
Regarding ST64B, are the ARM devices behind ARM SMMU v3 supposed to work
this way too? If not, EL0 can specify arbitrary PASID via ST64B with the
kernel today [1].
[1] https://github.com/torvalds/linux/blob/50897c955902c93ae71c38698abb910525ebdc89/arch/arm64/kernel/cpufeature.c#L3166-L3181
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role
From: Xu Yang @ 2026-05-12 9:58 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Franz Schnyder, Thinh.Nguyen, gregkh, shawnguo, s.hauer, kernel,
festevam, linux-usb, linux-kernel, imx, linux-arm-kernel, jun.li
In-Reply-To: <af8stIGhzVMfhyIQ@livingston.pivistrello.it>
On Sat, May 09, 2026 at 02:46:44PM +0200, Francesco Dolcini wrote:
> On Fri, May 08, 2026 at 06:04:49PM +0200, Franz Schnyder wrote:
> > On Fri, May 08, 2026 at 06:54:40PM +0800, Xu Yang wrote:
> > > It's strange that link->status is not DL_STATE_DORMANT or DL_STATE_NONE at
> > > the time which means the device core may not properly unbind consumer devices
> > > or handle something. The patch does a simple thing so the issue may not come
> > > from the patch itself.
> > >
> > > 1639: list_for_each_entry_safe_reverse(link, ln, &dev->links.consumers, s_node) {
> > > 1640: WARN_ON(link->status != DL_STATE_DORMANT &&
> > > 1641: link->status != DL_STATE_NONE);
> > > 1642: __device_link_del(&link->kref);
> > > 1643: }
> > >
> > > Which kernel and dtb are you using? If it's a downstream repo, how do the USB
> > > controller and related DTS nodes look like?
> >
> > I was using kernel version 7.1-rc2 and noticed it while working on
> > sending the Aquila iMX95 upstream.
> > https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
> > >
> > > Does the issue easily happen? Does dwc3_imx8mp_probe() eventually succeed?
> >
> > I did various boot attempts with the commit reverted and couldn't
> > reproduce the issue. With the commit I ran into the issue in about one
> > third of all boot attempts. So most of the time dwc3_imx8mp_prove
> > actually succeeds.
>
> ...
>
> > > Yes, if you use the new driver, I think this issue won't happen at all.
> > >
> > So once your work is merged in the imx95.dtsi we should be fine.
>
> To me it looks like a regression that should be taken care of.
>
> Maybe not relevant for aquila imx95, where you did reproduce it (the reason is
> that aquila imx95 is not in mainline, yet), but from the USB point of view this
> board is very similar to other boards using the i.MX95 SoC that are therefore
> likely affected.
Sure. I can't reproduce the issue now.
I'll research it when more information is given.
Thanks,
Xu Yang
^ permalink raw reply
* [PATCH v4 04/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with
corresponding clock-name "hclk". This clock is necessary for
the eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index a2640014ee04..b251bb129cdb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -285,8 +285,8 @@ hdmi1_out: port@1 {
edp1: edp@fded0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfded0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy1>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Icenowy Zheng @ 2026-05-12 10:01 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <dfbc4042-64cf-49f2-a5de-12260beffaa0@gmail.com>
在 2026-05-12二的 17:06 +0800，Joey Lu写道：
======= 8< =============
> > > > > diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > b/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > index 7a93049368db..225af322de32 100644
> > > > > --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > @@ -164,13 +164,16 @@ static void
> > > > > vs_bridge_enable_common(struct
> > > > > vs_crtc *crtc,
> > > > > VSDC_DISP_PANEL_CONFIG_CLK_EN);
> > > > > regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_CONFIG(output),
> > > > > VSDC_DISP_PANEL_CONFIG_RUNNING);
> > > > > - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> > > > > -
> > > > > VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> > > > > - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
> > > > > -
> > > > > VSDC_DISP_PANEL_START_RUNNING(output));
> > > > >
> > > > > - regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_CONFIG_EX(crtc-
> > > > > > id),
> > > > > - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> > > > > + if (dc->info->has_config_ex) {
> > > > > + regmap_clear_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_START,
> > > > > +
> > > > > VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> > > > > + regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_START,
> > > > > + VSDC_DISP_PANEL_START_RUNNIN
> > > > > G(ou
> > > > > tput
> > > > > ));
> > > > > +
> > > > > + regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
> > > > > + VSDC_DISP_PANEL_CONFIG_EX_CO
> > > > > MMIT
> > > > > );
> > > > Should the commit operation happen on DC8000/DCUltraLite too?
> > > > (By
> > > > writing to DcregFrameBufferConfig0.VALID).
> > > >
> > > > Many registers written has "Note: This field is double
> > > > buffered" in
> > > > the
> > > > DCUltraLite documentation.
> > > >
> > > > I suggest create a static function for commit -- write to the
> > > > corresponding commit bit on DC8200, and write to
> > > > DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
> > > [a] There is no commit operation for DCUltra Lite.
> > > I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID (BIT(3)) is a
> > > hardware-managed double-buffer status bit: hardware writes
> > > 1=PENDING
> > > when a new register set is ready and clears to 0=WORKING after
> > > the
> > > VBLANK copy. Software must never write it, and there is no
> > > polling
> > > use
> > It seems to be writable and controls whether register buffering is
> > enabled, see [1].
> >
> > The description of this bit in MA35D1 TRM says "This ensures a
> > frame
> > will always start with a valid working set if this register is
> > programmed last, which reduces the need for SW to wait for the
> > start of
> > a VBLANK signal in order to ensure all states are loaded before the
> > next VBLANK", which indicates some kind of "committing write",
> > although
> > the code at [1] seems to indicate that double buffering is only
> > enabled
> > when bit is cleared.
> >
> > Anyway this bit should be programmable, and "Software must never
> > write
> > it" contradicts with the MA35D1 TRM.
> >
> > Thanks,
> > Icenowy
> >
> > [1]
> > https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
> Thank you for the correction. I'll add
> `#define VSDC_FB_CONFIG_VALID BIT(3)` to vs_primary_plane_regs.h and
> write it in `vs_primary_plane_commit()` for non-config_ex variants.
> > > case in the driver that requires a named constant. For non-
> > > config_ex
> > > variants, `vs_primary_plane_commit()` performs no commit
> > > operation —
> > > `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
> > > `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET` (BIT(4)) is
> > > set/cleared in the bridge enable/disable paths.
Well according to the driver code for DC8000 from Eswin, and the bit
named "VALID", maybe it should be cleared before programming the
registers, and set after programming registers, to make the process of
programming registers atomic from the perspective of the display
controller.
Anyway this should require testing on real hardware to verify.
By the way, I see multiple peripheral drivers for MA35D1 get applied in
the torvalds tree, but the device tree is still only a skeleton; when
will the device tree be updated?
Thanks,
Icenowy
> > ========= 8< ==========
> >
^ permalink raw reply
* [PATCH v4 07/10] arm64: dts: rockchip: Add eDP node for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add full device tree definition for the integrated eDP controller
on RK3576, following the existing RK3588 hardware layout.
Configure required register range, clocks, interrupt, phy, power
domain, reset and grf properties to fully describe the controller.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v2:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 ++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index 28175d8200d5..733449cb88b1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -1496,6 +1496,34 @@ hdmi_out: port@1 {
};
};
+ edp: edp@27dc0000 {
+ compatible = "rockchip,rk3576-edp";
+ reg = <0x0 0x27dc0000 0x0 0x1000>;
+ clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO0_ROOT>;
+ clock-names = "dp", "pclk", "hclk";
+ interrupts = <GIC_SPI 365 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&hdptxphy>;
+ phy-names = "dp";
+ power-domains = <&power RK3576_PD_VO0>;
+ resets = <&cru SRST_EDP0_24M>, <&cru SRST_P_EDP0>;
+ reset-names = "dp", "apb";
+ rockchip,grf = <&vo0_grf>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port@0 {
+ reg = <0>;
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
dp: dp@27e40000 {
compatible = "rockchip,rk3576-dp";
reg = <0x0 0x27e40000 0x0 0x30000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3] dt-bindings: i2c: convert davinci i2c to dt-schema
From: Bartosz Golaszewski @ 2026-05-12 10:06 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: linux-i2c, devicetree, linux-kernel, linux-arm-kernel,
kernel test robot, andi.shyti, robh, krzk+dt, conor+dt, brgl
In-Reply-To: <20260512030032.5006-1-chaitanya.msabnis@gmail.com>
On Tue, 12 May 2026 05:00:32 +0200, Chaitanya Sabnis
<chaitanya.msabnis@gmail.com> said:
> Convert the Texas Instruments DaVinci and Keystone I2C controller
> bindings from legacy text format to modern dt-schema (YAML).
>
> During the conversion, the `interrupts` property was made required
> to match the strict requirement in the driver probe function. The
> custom `ti,has-pfunc` and `power-domains` properties were also
> properly defined to match SoC-specific hardware features.
>
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605120133.lQ1F3qlY-lkp@intel.com/
The report was on an earlier version. This patch is not a solution to a problem
spotted by the build bot itself. I'd just drop this line.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v3 1/7] PCI: Add pci_host_common_link_train_delay() helper
From: Hans Zhang @ 2026-05-12 10:06 UTC (permalink / raw)
To: Claudiu Beznea, bhelgaas, lpieralisi, kwilczynski, mani, vigneshr,
jingoohan1, thomas.petazzoni, pali, ryder.lee, claudiu.beznea.uj,
mpillai
Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <e092cd5d-6a46-4440-9085-95c929e8fb83@kernel.org>
On 5/12/26 15:05, Claudiu Beznea wrote:
> Hi, Hans,
>
> On 5/11/26 08:59, Hans Zhang wrote:
>> PCIe r6.0, sec 6.6.1 (Conventional Reset) requires that for a Downstream
>> Port supporting Link speeds greater than 5.0 GT/s, software must wait a
>> minimum of 100 ms after Link training completes before sending any
>> Configuration Request.
>>
>> Introduce a static inline helper pci_host_common_link_train_delay() that
>> checks the given max_link_speed (2 = 5.0 GT/s, 3 = 8.0 GT/s, etc.) and
>> calls msleep(100) only when the speed is greater than 5.0 GT/s.
>>
>> This allows multiple host controller drivers to share the same mandatory
>> delay without duplicating the logic.
>>
>> Signed-off-by: Hans Zhang <18255117159@163.com>
>> ---
>> drivers/pci/controller/pci-host-common.h | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pci-host-common.h b/drivers/pci/
>> controller/pci-host-common.h
>> index b5075d4bd7eb..d709f7e3e11a 100644
>> --- a/drivers/pci/controller/pci-host-common.h
>> +++ b/drivers/pci/controller/pci-host-common.h
>> @@ -10,6 +10,9 @@
>> #ifndef _PCI_HOST_COMMON_H
>> #define _PCI_HOST_COMMON_H
>> +#include <linux/delay.h>
>> +#include "../pci.h"
>> +
>> struct pci_ecam_ops;
>> int pci_host_common_probe(struct platform_device *pdev);
>> @@ -20,4 +23,18 @@ void pci_host_common_remove(struct platform_device
>> *pdev);
>> struct pci_config_window *pci_host_common_ecam_create(struct device
>> *dev,
>> struct pci_host_bridge *bridge, const struct pci_ecam_ops *ops);
>> +
>> +/**
>> + * pci_host_common_link_train_delay - Wait 100 ms if link speed > 5 GT/s
>> + * @max_link_speed: the maximum link speed (2 = 5.0 GT/s, 3 = 8.0 GT/
>> s, ...)
>> + *
>> + * Must be called after Link training completes and before the first
>> + * Configuration Request is sent.
>> + */
>> +static inline void pci_host_common_link_train_delay(int max_link_speed)
>> +{
>> + if (max_link_speed > 2)
>> + msleep(PCIE_RESET_CONFIG_WAIT_MS);
>
> In case of RZ/G3S driver the max_link_speed is populated based on "max-
> link-speed" DT property (by calling of_pci_get_max_link_speed()). My
> understanding from [1] (and the review of the initial RZ/G3S driver
> support) is that this is not a mandatory property (note also the "Host
> drivers *could* add this" from [1]). At least for the RZ/G3S driver, in
> case the "max-link-speed" DT property is not present in DT but the
> controller supports more than 5GT/s (that is possible as the driver
> supports more controller variants), the max_link_speed argument will be
> negative. In that case the msleep() will not be called. This looks like
> an opposite of what the patch set is trying to achieve.
Hi Claudiu,
The situation you mentioned also exists in the dwc common driver. My
understanding is that we are writing this driver at the normal rate
which is greater than GEN2. For some exceptions, or when the support is
greater than GEN2 but the actual operation is less than or equal to
GEN2, this situation might be unavoidable. Furthermore, for RZ/G3S, the
"max-link-speed" attribute can be added to the DT.
>
> Also, if I'm not wrong, there is also the possibility of having the max-
> link-speed > 2 but the downstream port to not support more than 5GT/s.
> In that case the mspeep() would also be executed (but I think that
> wouldn't be really an issue).
Before this patch, the RZ/G3S driver would always perform a msleep(100)
regardless of whether it was greater than GEN2 or less than or equal to
GEN2.
Best regards,
Hans
>
> Thank you,
> Claudiu
>
> [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/
> schemas/pci/pci-bus-common.yaml#L117
>
> Thank you,
> Claudiu
^ permalink raw reply
* Re: [PATCH net-next v3 5/6] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Maxime Chevallier @ 2026-05-12 10:06 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Andrew Lunn,
Heiner Kallweit, Russell King
Cc: kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260512-add-airoha-an8801-support-v3-5-1edb34e363ae@collabora.com>
Hi :)
This looks good, I just have very minimal comments
On 5/12/26 06:33, Louis-Alexis Eyraud wrote:
> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> Introduce a driver for the Airoha AN8801R Series Gigabit Ethernet
> PHY; this currently supports setting up PHY LEDs, 10/100M, 1000M
> speeds, and Wake on LAN and PHY interrupts.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
[...]
> +static u32 an8801r_led_blink_ms_to_hw(unsigned long req_ms)
> +{
> + u32 req_ns, regval;
> +
> + if (req_ms > AN8801_MAX_PERIOD_MS)
> + req_ms = AN8801_MAX_PERIOD_MS;
> +
> + req_ns = req_ms * 1000000;
Use NSEC_PER_MSEC :)
> +
> + /* Round to the nearest period unit... */
> + regval = req_ns + (AN8801_PERIOD_UNIT / 2);
> +
> + /* ...and now divide by the full period */
> + regval >>= AN8801_PERIOD_SHIFT;
> +
> + return regval;
> +}
> +
[...]
> +static int an8801r_led_hw_control_set(struct phy_device *phydev, u8 index,
> + unsigned long rules)
> +{
> + u16 on = 0, blink = 0;
> + int ret;
> +
> + if (index >= AN8801R_NUM_LEDS)
> + return -EINVAL;
> +
> + ret = an8801r_led_trig_to_hw(rules, &on, &blink);
> + if (ret)
> + return ret;
> +
> + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
> + LED_ON_EVT_MASK, on);
> + if (ret)
> + return ret;
> +
> + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_BLINK_CTRL(index),
> + LED_BLINK_EVT_MASK, blink);
> +
> + if (ret)
> + return ret;
Extra newline before the if()
> +
> + return phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
> + LED_ON_EN, on | blink ? LED_ON_EN : 0);
> +}
> +
[...]
> +static int an8801r_rgmii_rxdelay(struct phy_device *phydev, bool enable,
> + u16 delay_steps)
> +{
> + u32 reg_val;
> +
> + if (delay_steps > RGMII_DELAY_STEP_MASK)
> + return -EINVAL;
> +
> + if (enable) {
> + reg_val = delay_steps & RGMII_DELAY_STEP_MASK;
> +
> + /* Set align bit to add extra offset for RX delay */
> + reg_val |= RGMII_RXDELAY_ALIGN;
> +
> + /* Set force mode bit to enable RX delay insertion */
> + reg_val |= RGMII_RXDELAY_FORCE_MODE;
> + } else {
> + reg_val = 0;
> + }
> +
> + return an8801_buckpbus_reg_write(phydev, AN8801_BPBUS_REG_RXDLY_STEP,
> + reg_val);
> +}
> +
> +static int an8801r_rgmii_txdelay(struct phy_device *phydev, bool enable,
> + u16 delay_steps)
> +{
> + u32 reg_val;
> +
> + if (delay_steps > RGMII_DELAY_STEP_MASK)
> + return -EINVAL;
> +
> + if (enable) {
> + reg_val = delay_steps & RGMII_DELAY_STEP_MASK;
Is this bitwise and needed, as you have the check above ?
> +
> + /* Set force mode bit to enable TX delay insertion */
> + reg_val |= RGMII_TXDELAY_FORCE_MODE;
> + } else {
> + reg_val = 0;
> + }
> +
> + return an8801_buckpbus_reg_write(phydev, AN8801_BPBUS_REG_TXDLY_STEP,
> + reg_val);
> +}
> +
> +static int an8801r_rgmii_delay_config(struct phy_device *phydev)
> +{
> + bool enable_delay;
> + u16 delay_step;
> + int ret;
> +
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> + enable_delay = true;
> + delay_step = AN8801_RGMII_TXDELAY_DEFAULT;
> + } else {
> + enable_delay = false;
> + delay_step = RGMII_DELAY_NO_STEP;
> + }
> +
> + ret = an8801r_rgmii_txdelay(phydev, enable_delay, delay_step);
> + if (ret)
> + return ret;
> +
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> + enable_delay = true;
> + delay_step = AN8801_RGMII_RXDELAY_DEFAULT;
Is it correct that AN8801_RGMII_RXDELAY_DEFAULT expands to
RGMII_DELAY_NO_STEP ? feels strange, but it may simply be how the HW is
made :)
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH v3 4/7] PCI: dwc: Use common pci_host_common_link_train_delay() helper
From: Hans Zhang @ 2026-05-12 10:06 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: bhelgaas, lpieralisi, mani, vigneshr, jingoohan1,
thomas.petazzoni, pali, ryder.lee, claudiu.beznea.uj, mpillai,
robh, s-vadapalli, linux-omap, linux-arm-kernel, claudiu.beznea,
linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <20260512071328.GA3606279@rocinante>
On 5/12/26 15:14, Krzysztof Wilczyński wrote:
> Hello,
>
>>>> - /*
>>>> - * As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link
>>>> - * speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms
>>>> - * after Link training completes before sending a Configuration Request.
>>>> - */
>>>> - if (pci->max_link_speed > 2)
>>>> - msleep(PCIE_RESET_CONFIG_WAIT_MS);
>>>> + pci_host_common_link_train_delay(pci->max_link_speed);
>>>
>>> This comment could move to the helper you added.
>>
>> Hi Krzysztof,
>>
>> Will add.
>
> No need. Per Mani's feedback about macro being well documented.
>
Hi Krzysztof,
Okay.
Best regards,
Hans
> Thank you nonetheless!
>
> Krzysztof
^ permalink raw reply
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Joonwon Kang @ 2026-05-12 10:07 UTC (permalink / raw)
To: jgg
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan, iommu,
jacob.jun.pan, joonwonkang, joro, jpb, kees, kevin.tian,
linux-arm-kernel, linux-kernel, nicolinc, praan, robin.murphy,
smostafa, will
In-Reply-To: <20260509171013.GF9285@ziepe.ca>
> > We have multiple processes and a single device, those processes want to
> > do SVA with the same device, and only one process will do SVA with the
> > device at a time. Though, the problem occurs even when irrelevant
> > processes allocate the PASIDs from the global PASID space for their own
> > irrelevant purposes.
>
> The only way to allocate a PASID from the global PASID space is to
> establish another SVA, so you have multiple devices doing SVA?
Another way is via iommu_alloc_global_pasid() [1] and it does not require
SVA. No, we currently do not have multiple devices doing SVA. But, the
problem is that it is out of our control when any device is to allocate a
PASID or do SVA for its own purpose.
[1] https://lore.kernel.org/all/20230802212427.1497170-3-jacob.jun.pan@linux.intel.com/
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v5 8/8] unwind: arm64: Use sframe to unwind interrupt frames
From: Mark Rutland @ 2026-05-12 10:07 UTC (permalink / raw)
To: Dylan Hatch
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Jens Remus, Prasanna Kumar T S M, Puranjay Mohan,
Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
live-patching, linux-arm-kernel, Randy Dunlap
In-Reply-To: <CADBMgpx9YxNUO6wLP7mYKxWW8L78Hk9gPwHrMjXUwPyUmGEu9w@mail.gmail.com>
On Mon, May 11, 2026 at 08:00:21PM -0700, Dylan Hatch wrote:
> Hi Mark,
>
> Thanks for all the feedback and help on this. I'm planning on getting
> your comments addressed in the coming days, but I have some initial
> clarifying questions.
>
> On Fri, May 1, 2026 at 9:46 AM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > Hi Dylan,
> >
> > Thanks for putting this together. I think this is looking pretty good.
> > However, there are some things that aren't quite right and need some
> > work, which I've commented on below.
> >
> > More generally, there are a few things that aren't addressed by this
> > series that we will also need to address. Importantly:
> >
> > (1) For correctness, we'll need to address a latent issue with unwinding
> > across an fgraph return trampoline, where the return address is
> > transiently unrecoverable.
> >
> > Before this series, that doesn't matter for livepatching because the
> > livepatching code isn't called synchronously within the fgraph
> > handler, and unwinds which cross an exception boundary are marked as
> > unreliable.
> >
> > After this series, that does matter as we can unwind across an
> > exception boundary, and might happen to interrupt that transient
> > window.
> >
> > I think we can solve that with some restructuring of that code,
> > restoring the original address *before* removing that from the
> > fgraph return stack, and ensuring that the unwinder can find it.
>
> If my understanding is correct, the issue arrises in return_to_handler
> as the return address is recovered:
>
> mov x0, sp
> bl ftrace_return_to_handler // addr = ftrace_return_to_hander(fregs);
> mov x30, x0 // restore the original return address
>
> Because ftrace_return_to_handler pops the return address from the
> return stack before it can be restored into the LR, it cannot be
> recovered.
Yes.
To be clear, please don't worry about solving that for the next version
of this series; let's get the SFrame bits into shape first. I just
wanted to highlight that there's some more general work that we'll need
to do.
I think we can *detect* this case (and mark the unwind as unreliable)
with some tiny changes to the arm64 code. I'm happy to put that
together.
> Based on this, I believe you are suggesting to restructure this code
> path such that the return address is removed from the return stack
> only after it has been restored to LR. But since kernel/trace/fgraph.c
> is core kernel code, will this end up requiring either (1) a similar
> restructuring of other arches supporting ftrace, or (2) an
> arm64-specific implementation of this recovery logic?
Yes, I am say that to *recover* the address we'd need to make changes to
core code.
In the mean time we can *detect* this case with some minimal changes to
arm64 code, and abort. As above, I'm happy to go put that together.
> It looks to me like there is essentially the same recovery pattern on
> other arches; is there a reason this transient unrecoverability isn't
> an issue for reliable unwind on other platforms?
Yep; on all architectures there's a transient period where the address
cannot be recovered. It's not a correctness issue so long as the
architecture detects this case and marks the unwind as unreliable.
IIUC x86 will mark the unwind as unreliable in this case.
I don't know whether other architectures detect this reliably. That's a
question for loonarch, parisc, powerpc, and s390 folk.
> > I'm not immediately sure whether kretprobes has a similar issue.
> >
> > (2) To make unwinding generally possible, we'll need to annotate some
> > assembly functions as unwindable. We'll need to do that for string
> > routines under lib/, and probably some crypto code, but we don't
> > need to do that for most code in head.S, entry.S, etc.
> >
> > The vast majority of relevant assembly functions are leaf functions
> > (where the return address is never moved out of the LR), so we can
> > probably get away with a simple annotation for those that avoids the
> > need for open-coded CFI directives everywhere.
>
> Are you suggesting something like a SYM_LEAF_FUNC_(START|END), that
> wraps CFI directives for leaf functions?
Yep; that's exactly the sort of thing I was thinking of.
That or have a seaprate annotation we can add, e.g.
SYM_FUNC_START(foo)
SYM_FUN_END(foo)
SYM_FUNC_IS_LEAF_AND_DOES_NOT_TOUCH_LR(foo)
> > I've pushed some reliable stacktrace tests to:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git stacktrace/tests
> >
> > That finds the fgraph issue (regardless of this series). When merged
> > with this series triggers a warning in kunwind_next_frame_record_meta(),
> > where unwind_next_frame_sframe() calls that erroneously as a fallback.
>
> Thanks for the pointer on these tests, they're super useful! I've been
> able to reproduce the fgraph failure you mentioned.
Great!
Mark.
^ permalink raw reply
* [PATCH v2] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
From: Xu Yang @ 2026-05-12 10:10 UTC (permalink / raw)
To: vkoul, neil.armstrong, Frank.Li, s.hauer, kernel, festevam,
jun.li, a.fatoum, franz.schnyder, stefano.radaelli21, linux-phy,
imx, linux-arm-kernel, linux-kernel
USB remote wakeup need its PHY power domain to be active,
so set PHY to be wakeup capable.
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- no changes
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 958d114b0c83..50b67f1e6a90 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -750,6 +750,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
"failed to get tca\n");
imx8m_get_phy_tuning_data(imx_phy);
+ device_set_wakeup_capable(dev, true);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
--
2.34.1
^ permalink raw reply related
* [PATCH v2] phy: fsl-imx8mq-usb: add control register regmap
From: Xu Yang @ 2026-05-12 10:12 UTC (permalink / raw)
To: vkoul, neil.armstrong, Frank.Li, s.hauer, kernel, festevam,
jun.li, a.fatoum, franz.schnyder, stefano.radaelli21, linux-phy,
imx, linux-arm-kernel, linux-kernel
The CR port is a simple 16-bit data/address parallel port that is
provided for on-chip access to the control registers inside the
USB 3.0 femtoPHY. Add control register regmap and export these
registers by debugfs to help PHY's diagnostic.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- no changes
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index b05d80e849a1..958d114b0c83 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0+
-/* Copyright (c) 2017 NXP. */
+/* Copyright 2017-2026 NXP. */
#include <linux/bitfield.h>
#include <linux/clk.h>
@@ -9,6 +9,7 @@
#include <linux/of.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/usb/typec_mux.h>
@@ -55,6 +56,8 @@
#define PHY_CTRL6_ALT_CLK_EN BIT(1)
#define PHY_CTRL6_ALT_CLK_SEL BIT(0)
+#define PHY_CRCTL 0x30
+
#define PHY_TUNE_DEFAULT 0xffffffff
#define TCA_CLK_RST 0x00
@@ -118,6 +121,7 @@ struct imx8mq_usb_phy {
void __iomem *base;
struct regulator *vbus;
struct tca_blk *tca;
+ struct regmap *cr_regmap;
u32 pcs_tx_swing_full;
u32 pcs_tx_deemph_3p5db;
u32 tx_vref_tune;
@@ -685,6 +689,14 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
};
MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
+static const struct regmap_config imx_cr_regmap_config = {
+ .name = "cr",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x7,
+};
+
static int imx8mq_usb_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -713,6 +725,11 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (IS_ERR(imx_phy->base))
return PTR_ERR(imx_phy->base);
+ imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
+ &imx_cr_regmap_config);
+ if (IS_ERR(imx_phy->cr_regmap))
+ return PTR_ERR(imx_phy->cr_regmap);
+
phy_ops = of_device_get_match_data(dev);
if (!phy_ops)
return -EINVAL;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 12/20] drm/crtc: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-05-12 10:16 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260504172858.GO1344263@killaraus.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 4008 bytes --]
Hi,
On Mon, May 04, 2026 at 08:28:58PM +0300, Laurent Pinchart wrote:
> On Fri, Apr 24, 2026 at 12:18:52PM +0200, Maxime Ripard wrote:
> > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> > to drm_private_obj") introduced a new pattern for allocating drm object
> > states.
> >
> > Instead of relying on the reset() callback, it created a new
> > atomic_create_state hook. This is helpful because reset is a bit
> > overloaded: it's used to create the initial software state, reset it,
> > but also reset the hardware.
> >
> > It can also be used either at probe time, to create the initial state
> > and possibly reset the hardware to an expected default, but also during
> > suspend/resume.
> >
> > Both these cases come with different expectations too: during the
> > initialization, we want to initialize all states, but during
> > suspend/resume, drm_private_states for example are expected to be kept
> > around.
> >
> > reset() also isn't fallible, which makes it harder to handle
> > initialization errors properly. This is only really relevant for some
> > drivers though, since all the helpers for reset only create a new
> > state, and don't touch the hardware at all.
> >
> > It was thus decided to create a new hook that would allocate and
> > initialize a pristine state without any side effect:
> > atomic_create_state to untangle a bit some of it, and to separate the
> > initialization with the actual reset one might need during a
> > suspend/resume.
> >
> > Continue the transition to the new pattern with CRTCs.
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 47 +++++++++++++++++++++++++++++++
> > drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++-
> > include/drm/drm_atomic_state_helper.h | 4 +++
> > include/drm/drm_crtc.h | 16 +++++++++++
> > 4 files changed, 87 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 9cd8550cabb7..b7da134c8c50 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -103,10 +103,32 @@ __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> >
> > crtc->state = crtc_state;
> > }
> > EXPORT_SYMBOL(__drm_atomic_helper_crtc_reset);
> >
> > +/**
> > + * __drm_atomic_helper_crtc_create_state - initializes crtc state
>
> "Initialize a CRTC state"
Good catch, thanks.
> The name of the function is misleading ("*_create_*" while you state it
> performs initialization).
>
> > + * @crtc: crtc object
> > + * @state: new state to initialize
> > + *
> > + * Initializes the newly allocated @state, usually required when
> > + * initializing the drivers.
> > + *
> > + * @state is assumed to be zeroed.
> > + *
> > + * This is useful for drivers that subclass @drm_crtc_state.
> > + */
> > +void __drm_atomic_helper_crtc_create_state(struct drm_crtc *crtc,
> > + struct drm_crtc_state *state)
> > +{
> > + __drm_atomic_helper_crtc_state_init(state, crtc);
> > +
> > + if (drm_dev_has_vblank(crtc->dev))
> > + drm_crtc_vblank_reset(crtc);
>
> This is confusing to me (at least before reading the rest of the
> series), and itn't mentioned in the function documentation or in the
> commit message.
>
> Furthermore, __drm_atomic_helper_crtc_create_state() is later used in
> tidss_crtc_create_state(), which is the
> drm_crtc_funcs.atomic_create_state() implementation of the tidss driver.
> The atomic_create_state documentation states that "This callback must
> have no side effect", and drm_crtc_vblank_reset() has side effects.
That's a good point. I've dropped that function entirely and moved the
drm_crtc_vblank_reset() call in drm_mode_config_crtc_create_state().
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* [PATCH v3 4/6] regulator: mt6359: const-ify regulator descriptions
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260512085358.1693208-1-wenst@chromium.org>
The regulator descriptions and extended descriptions don't change at
runtime. The only reason they are not const is that the regulator
driver data is non-const.
Const-ify the descriptions and all references to them. For the driver
data, explicitly cast it to non-const void *.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/regulator/mt6359-regulator.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index c8a788858824..bcf9a476a34e 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -251,7 +251,7 @@ static int mt6359_get_status(struct regulator_dev *rdev)
{
int ret;
u32 regval;
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
ret = regmap_read(rdev->regmap, info->status_reg, ®val);
if (ret != 0) {
@@ -267,7 +267,7 @@ static int mt6359_get_status(struct regulator_dev *rdev)
static unsigned int mt6359_regulator_get_mode(struct regulator_dev *rdev)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret, regval;
ret = regmap_read(rdev->regmap, info->modeset_reg, ®val);
@@ -299,7 +299,7 @@ static unsigned int mt6359_regulator_get_mode(struct regulator_dev *rdev)
static int mt6359_regulator_set_mode(struct regulator_dev *rdev,
unsigned int mode)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret = 0, val;
int curr_mode;
@@ -354,7 +354,7 @@ static int mt6359_regulator_set_mode(struct regulator_dev *rdev,
static int mt6359p_vemc_set_voltage_sel(struct regulator_dev *rdev,
u32 sel)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret;
u32 val = 0;
@@ -393,7 +393,7 @@ static int mt6359p_vemc_set_voltage_sel(struct regulator_dev *rdev,
static int mt6359p_vemc_get_voltage_sel(struct regulator_dev *rdev)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret;
u32 val = 0;
@@ -469,7 +469,7 @@ static const struct regulator_ops mt6359p_vemc_ops = {
};
/* The array is indexed by id(MT6359_ID_XXX) */
-static struct mt6359_regulator_info mt6359_regulators[] = {
+static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
@@ -705,7 +705,7 @@ static struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
};
-static struct mt6359_regulator_info mt6359p_regulators[] = {
+static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
@@ -950,7 +950,7 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
struct mt6397_chip *mt6397 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = {};
struct regulator_dev *rdev;
- struct mt6359_regulator_info *mt6359_info;
+ const struct mt6359_regulator_info *mt6359_info;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
@@ -965,7 +965,8 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
for (i = 0; i < MT6359_MAX_REGULATOR; i++, mt6359_info++) {
- config.driver_data = mt6359_info;
+ /* drop const here, but all uses in the driver are const */
+ config.driver_data = (void *)mt6359_info;
rdev = devm_regulator_register(&pdev->dev, &mt6359_info->desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
--
2.54.0.563.g4f69b47b94-goog
^ 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