From: sashiko-bot@kernel.org
To: "Michal Wilczynski" <m.wilczynski@samsung.com>
Cc: mfd@lists.linux.dev, robh@kernel.org, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, olteanv@gmail.com,
conor+dt@kernel.org, lee@kernel.org,
dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org,
vkoul@kernel.org, linux-phy@lists.infradead.org
Subject: Re: [PATCH v3 14/19] drm/bridge: starfive: Add JH7110 HDMI controller driver
Date: Fri, 04 Sep 2026 13:57:08 +0000 [thread overview]
Message-ID: <20260904135709.41DFB1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904-jh7110-clean-send-v3-14-484f9ae72715@samsung.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `regmap` variable is assigned and checked but never used or passed to the generic driver, contradicting the commit message.
- [Medium] Missing mandatory `phy_init()` and `phy_exit()` calls for the HDMI PHY.
--
commit a25b9a0e71017577ee552276d0b9a0aa22a5f9f0
Author: Michal Wilczynski <m.wilczynski@samsung.com>
drm/bridge: starfive: Add JH7110 HDMI controller driver
This commit adds the HDMI controller (bridge) driver for the StarFive
JH7110. It registers as a DRM bridge, manages clock rates and PHY power,
and configures the mux setting based on the port graph.
> The driver calls the generic inno_hdmi_probe function and passes the
> shared regmap to it, registering as a DRM bridge.
[Severity: Medium]
Is this description accurate regarding the regmap? Looking at the
starfive_inno_hdmi_controller_probe() function below, the regmap is fetched
but doesn't appear to actually be passed to inno_hdmi_probe() or used
anywhere else.
> diff --git a/drivers/gpu/drm/bridge/jh7110-inno-hdmi.c b/drivers/gpu/drm/bridge/jh7110-inno-hdmi.c
> new file mode 100644
> index 0000000000000..b0bf6abaa55fb
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/jh7110-inno-hdmi.c
[ ... ]
> +static void inno_hdmi_starfive_enable(struct device *dev,
> + struct drm_display_mode *mode)
> +{
[ ... ]
> + /*
> + * 3. Power on the PHY. This calls the PHY driver's .power_on op,
> + * which configures the Post-PLL and analog blocks.
> + */
> + ret = phy_power_on(ctrl->phy);
[Severity: Medium]
Does this code omit a required initialization step? The generic PHY API
strictly requires phy_init() to be called before phy_power_on(). Even if
the current starfive-inno-hdmi-phy driver lacks an .init callback, omitting
phy_init() here violates the API contract and could lead to initialization
failures if the PHY driver is updated or a different PHY is bound.
> + if (ret) {
> + dev_err(dev, "Failed to power on PHY: %d\n", ret);
> + clk_disable_unprepare(ctrl->clks[CLK_PCLK].clk);
> + return;
> + }
> +
> + ctrl->enabled = true;
> +}
> +
> +static void inno_hdmi_starfive_disable(struct device *dev)
> +{
> + struct stf_inno_hdmi_controller *ctrl = dev_get_drvdata(dev);
> +
> + /*
> + * .enable bails out early if the pixel clock rate is unsupported or
> + * the PHY fails to power on, leaving pclk and the PHY untouched.
> + * Only tear down what was actually brought up, otherwise the clock
> + * refcount underflows.
> + */
> + if (!ctrl->enabled)
> + return;
> +
> + phy_power_off(ctrl->phy);
[Severity: Medium]
Should there be a call to phy_exit() here? Following the same API contract,
phy_exit() should generally be invoked to clean up resources after
phy_power_off() completes.
> + clk_disable_unprepare(ctrl->clks[CLK_PCLK].clk);
> + ctrl->enabled = false;
> +}
[ ... ]
> +static int starfive_inno_hdmi_controller_probe(struct platform_device *pdev)
> +{
[ ... ]
> + /* Get the shared regmap from the parent */
> + regmap = dev_get_regmap(parent, NULL);
> + if (!regmap) {
> + dev_err(dev, "Failed to get parent regmap\n");
> + return -ENODEV;
> + }
[Severity: Medium]
Could this be dead code? The regmap is fetched and checked here, but
subsequent code within starfive_inno_hdmi_controller_probe() never uses it.
[ ... ]
> + plat_data = of_device_get_match_data(dev);
> +
> + /* Hand off to the generic library to create the bridge. */
> + inno = inno_hdmi_probe(pdev, plat_data);
[Severity: Medium]
As mentioned regarding the commit message, should the regmap have been
passed to inno_hdmi_probe() here?
> + if (IS_ERR(inno))
> + return PTR_ERR(inno);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904-jh7110-clean-send-v3-0-484f9ae72715@samsung.com?part=14
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Michal Wilczynski" <m.wilczynski@samsung.com>
Cc: mfd@lists.linux.dev, robh@kernel.org, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, olteanv@gmail.com,
conor+dt@kernel.org, lee@kernel.org,
dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org,
vkoul@kernel.org, linux-phy@lists.infradead.org
Subject: Re: [PATCH v3 14/19] drm/bridge: starfive: Add JH7110 HDMI controller driver
Date: Fri, 04 Sep 2026 13:57:08 +0000 [thread overview]
Message-ID: <20260904135709.41DFB1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904-jh7110-clean-send-v3-14-484f9ae72715@samsung.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `regmap` variable is assigned and checked but never used or passed to the generic driver, contradicting the commit message.
- [Medium] Missing mandatory `phy_init()` and `phy_exit()` calls for the HDMI PHY.
--
commit a25b9a0e71017577ee552276d0b9a0aa22a5f9f0
Author: Michal Wilczynski <m.wilczynski@samsung.com>
drm/bridge: starfive: Add JH7110 HDMI controller driver
This commit adds the HDMI controller (bridge) driver for the StarFive
JH7110. It registers as a DRM bridge, manages clock rates and PHY power,
and configures the mux setting based on the port graph.
> The driver calls the generic inno_hdmi_probe function and passes the
> shared regmap to it, registering as a DRM bridge.
[Severity: Medium]
Is this description accurate regarding the regmap? Looking at the
starfive_inno_hdmi_controller_probe() function below, the regmap is fetched
but doesn't appear to actually be passed to inno_hdmi_probe() or used
anywhere else.
> diff --git a/drivers/gpu/drm/bridge/jh7110-inno-hdmi.c b/drivers/gpu/drm/bridge/jh7110-inno-hdmi.c
> new file mode 100644
> index 0000000000000..b0bf6abaa55fb
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/jh7110-inno-hdmi.c
[ ... ]
> +static void inno_hdmi_starfive_enable(struct device *dev,
> + struct drm_display_mode *mode)
> +{
[ ... ]
> + /*
> + * 3. Power on the PHY. This calls the PHY driver's .power_on op,
> + * which configures the Post-PLL and analog blocks.
> + */
> + ret = phy_power_on(ctrl->phy);
[Severity: Medium]
Does this code omit a required initialization step? The generic PHY API
strictly requires phy_init() to be called before phy_power_on(). Even if
the current starfive-inno-hdmi-phy driver lacks an .init callback, omitting
phy_init() here violates the API contract and could lead to initialization
failures if the PHY driver is updated or a different PHY is bound.
> + if (ret) {
> + dev_err(dev, "Failed to power on PHY: %d\n", ret);
> + clk_disable_unprepare(ctrl->clks[CLK_PCLK].clk);
> + return;
> + }
> +
> + ctrl->enabled = true;
> +}
> +
> +static void inno_hdmi_starfive_disable(struct device *dev)
> +{
> + struct stf_inno_hdmi_controller *ctrl = dev_get_drvdata(dev);
> +
> + /*
> + * .enable bails out early if the pixel clock rate is unsupported or
> + * the PHY fails to power on, leaving pclk and the PHY untouched.
> + * Only tear down what was actually brought up, otherwise the clock
> + * refcount underflows.
> + */
> + if (!ctrl->enabled)
> + return;
> +
> + phy_power_off(ctrl->phy);
[Severity: Medium]
Should there be a call to phy_exit() here? Following the same API contract,
phy_exit() should generally be invoked to clean up resources after
phy_power_off() completes.
> + clk_disable_unprepare(ctrl->clks[CLK_PCLK].clk);
> + ctrl->enabled = false;
> +}
[ ... ]
> +static int starfive_inno_hdmi_controller_probe(struct platform_device *pdev)
> +{
[ ... ]
> + /* Get the shared regmap from the parent */
> + regmap = dev_get_regmap(parent, NULL);
> + if (!regmap) {
> + dev_err(dev, "Failed to get parent regmap\n");
> + return -ENODEV;
> + }
[Severity: Medium]
Could this be dead code? The regmap is fetched and checked here, but
subsequent code within starfive_inno_hdmi_controller_probe() never uses it.
[ ... ]
> + plat_data = of_device_get_match_data(dev);
> +
> + /* Hand off to the generic library to create the bridge. */
> + inno = inno_hdmi_probe(pdev, plat_data);
[Severity: Medium]
As mentioned regarding the commit message, should the regmap have been
passed to inno_hdmi_probe() here?
> + if (IS_ERR(inno))
> + return PTR_ERR(inno);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904-jh7110-clean-send-v3-0-484f9ae72715@samsung.com?part=14
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-09-04 13:57 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260904132708eucas1p1adfa26ef0fe5109eca63a3aeadf74915@eucas1p1.samsung.com>
2026-09-04 13:27 ` [PATCH v3 00/19] drm: starfive: jh7110: Enable display subsystem Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` [PATCH v3 01/19] dt-bindings: phy: Add starfive,jh7110-inno-hdmi-phy Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:30 ` sashiko-bot
2026-09-04 13:30 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 02/19] dt-bindings: display: bridge: Add starfive,jh7110-inno-hdmi-controller Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:35 ` sashiko-bot
2026-09-04 13:35 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 03/19] dt-bindings: mfd: Add starfive,jh7110-hdmi-subsystem Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:37 ` sashiko-bot
2026-09-04 13:37 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 04/19] dt-bindings: soc: starfive: Add starfive,jh7110-vout-syscon Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:30 ` sashiko-bot
2026-09-04 13:30 ` sashiko-bot
2026-09-10 8:18 ` Krzysztof Kozlowski
2026-09-10 8:18 ` Krzysztof Kozlowski
2026-09-10 8:18 ` Krzysztof Kozlowski
2026-09-10 8:18 ` Krzysztof Kozlowski
2026-09-04 13:27 ` [PATCH v3 05/19] dt-bindings: soc: starfive: Add starfive,jh7110-vout-subsystem Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:36 ` sashiko-bot
2026-09-04 13:36 ` sashiko-bot
2026-09-10 8:21 ` Krzysztof Kozlowski
2026-09-10 8:21 ` Krzysztof Kozlowski
2026-09-10 8:21 ` Krzysztof Kozlowski
2026-09-10 8:21 ` Krzysztof Kozlowski
2026-09-04 13:27 ` [PATCH v3 06/19] dt-bindings: display: verisilicon: Add starfive,jh7110-dc8200 Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:31 ` sashiko-bot
2026-09-04 13:31 ` sashiko-bot
2026-09-10 8:34 ` Krzysztof Kozlowski
2026-09-10 8:34 ` Krzysztof Kozlowski
2026-09-10 8:34 ` Krzysztof Kozlowski
2026-09-10 8:34 ` Krzysztof Kozlowski
2026-09-04 13:27 ` [PATCH v3 07/19] drm/bridge: inno-hdmi: Split probe out of bind Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:42 ` sashiko-bot
2026-09-04 13:42 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 08/19] drm/bridge: inno-hdmi: Allow the register map to come from a parent Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:43 ` sashiko-bot
2026-09-04 13:43 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 09/19] drm/bridge: inno-hdmi: Add .disable platform operation Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:49 ` sashiko-bot
2026-09-04 13:49 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 10/19] drm/bridge: inno-hdmi: Add .mode_valid " Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:40 ` sashiko-bot
2026-09-04 13:40 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 11/19] soc: starfive: Add jh7110-hdmi-subsystem driver Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:52 ` sashiko-bot
2026-09-04 13:52 ` sashiko-bot
2026-09-07 8:23 ` Uwe Kleine-König
2026-09-07 8:23 ` Uwe Kleine-König
2026-09-07 8:23 ` Uwe Kleine-König
2026-09-07 8:23 ` Uwe Kleine-König
2026-09-04 13:27 ` [PATCH v3 12/19] soc: starfive: Add jh7110-vout-subsystem driver Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:47 ` sashiko-bot
2026-09-04 13:47 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 13/19] clk: starfive: jh7110-vout: Allow pixel clock rate propagation Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:44 ` sashiko-bot
2026-09-04 13:44 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 14/19] drm/bridge: starfive: Add JH7110 HDMI controller driver Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:39 ` Icenowy Zheng
2026-09-04 13:39 ` Icenowy Zheng
2026-09-04 13:39 ` Icenowy Zheng
2026-09-04 13:39 ` Icenowy Zheng
2026-09-04 13:57 ` sashiko-bot [this message]
2026-09-04 13:57 ` sashiko-bot
2026-09-07 3:51 ` Chaoyi Chen
2026-09-07 3:51 ` Chaoyi Chen
2026-09-07 3:51 ` Chaoyi Chen
2026-09-07 3:51 ` Chaoyi Chen
2026-09-04 13:27 ` [PATCH v3 15/19] phy: Add common Innosilicon HDMI PHY helpers Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:55 ` sashiko-bot
2026-09-04 13:55 ` sashiko-bot
2026-09-07 3:16 ` Chaoyi Chen
2026-09-07 3:16 ` Chaoyi Chen
2026-09-07 3:16 ` Chaoyi Chen
2026-09-07 3:16 ` Chaoyi Chen
2026-09-04 13:27 ` [PATCH v3 16/19] phy: rockchip: inno-hdmi: Use the common Innosilicon " Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:59 ` sashiko-bot
2026-09-04 13:59 ` sashiko-bot
2026-09-07 3:20 ` Chaoyi Chen
2026-09-07 3:20 ` Chaoyi Chen
2026-09-07 3:20 ` Chaoyi Chen
2026-09-07 3:20 ` Chaoyi Chen
2026-09-04 13:27 ` [PATCH v3 17/19] phy: starfive: Add jh7110-inno-hdmi-phy driver Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:57 ` sashiko-bot
2026-09-04 13:57 ` sashiko-bot
2026-09-04 13:27 ` [PATCH v3 18/19] riscv: dts: starfive: jh7110: Update DT for display subsystem Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 14:03 ` sashiko-bot
2026-09-04 14:03 ` sashiko-bot
2026-09-10 8:37 ` Krzysztof Kozlowski
2026-09-10 8:37 ` Krzysztof Kozlowski
2026-09-10 8:37 ` Krzysztof Kozlowski
2026-09-10 8:37 ` Krzysztof Kozlowski
2026-09-04 13:27 ` [PATCH v3 19/19] MAINTAINERS: Add StarFive JH7110 display subsystem entry Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 13:27 ` Michal Wilczynski
2026-09-04 15:13 ` [PATCH v3 00/19] drm: starfive: jh7110: Enable display subsystem Joshua Peisach
2026-09-04 15:13 ` Joshua Peisach
2026-09-04 15:13 ` Joshua Peisach
2026-09-04 15:13 ` Joshua Peisach
2026-09-05 5:21 ` Maud Spierings
2026-09-05 5:21 ` Maud Spierings
2026-09-05 5:21 ` Maud Spierings
2026-09-05 5:21 ` Maud Spierings
2026-09-06 3:55 ` Dominique Belhachemi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260904135709.41DFB1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=lee@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=m.wilczynski@samsung.com \
--cc=mfd@lists.linux.dev \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.