All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Francesco Dolcini" <francesco@dolcini.it>
Cc: robh@kernel.org, conor+dt@kernel.org, imx@lists.linux.dev,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Frank.Li@kernel.org
Subject: Re: [PATCH v2 2/4] drm/bridge: Add THine THC63LVD827 LVDS encoder
Date: Mon, 05 Oct 2026 10:09:42 +0000	[thread overview]
Message-ID: <20261005100943.1A2711F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261005095006.20290-3-francesco@dolcini.it>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/bridge: back-powering via GPIOs on unpowered chip
--

commit b3195cf0e052ea83d4890e15599f3b4469d3b2e4
Author: Francesco Dolcini <francesco.dolcini@toradex.com>

drm/bridge: Add THine THC63LVD827 LVDS encoder

This commit introduces a new DRM bridge driver for the THine THC63LVD827 DPI
to LVDS bridge. The driver provides support for configuring the LVDS data
mapping, GPIO-based control pins, and regulator power supplies.

> diff --git a/drivers/gpu/drm/bridge/thc63lvd827.c b/drivers/gpu/drm/bridge/thc63lvd827.c
> new file mode 100644
> index 0000000000000..02b97d1cc71ea
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd827.c
[ ... ]
> +static void thc63lvd827_atomic_post_disable(struct drm_bridge *bridge,
> +					    struct drm_atomic_commit *state)
> +{
> +	struct thc63lvd827 *thc63lvd827 = bridge_to_thc63lvd827(bridge);
> +	int ret;
> +
> +	gpiod_set_value_cansleep(thc63lvd827->pd_gpio, 1);
> +
> +	ret = regulator_bulk_disable(ARRAY_SIZE(thc63lvd827_supplies),
> +				     thc63lvd827->supplies);

[Severity: Medium]
Does this sequence leave the chip exposed to back-powering?

The regulators are disabled here, cutting power to the chip, but the driver
does not reset the b6b8, map, or mode GPIOs to a safe physical low state first.
These pins remain driven in their previously asserted physical HIGH states,
causing continuous back-powering while the display is disabled.

Hardware back-powering causes leakage current through ESD diodes into the
unpowered chip's VDD net, which can lead to latch-up, increased power
consumption during suspend, or improper power-on reset sequencing.

[ ... ]
> +static int thc63lvd827_probe(struct platform_device *pdev)
> +{
[ ... ]
> +	thc63lvd827->map_gpio = devm_gpiod_get_optional(dev, "map", GPIOD_OUT_LOW);
> +	if (IS_ERR(thc63lvd827->map_gpio))
> +		return dev_err_probe(dev, PTR_ERR(thc63lvd827->map_gpio),
> +				     "failed to get MAP GPIO\n");
> +
> +	thc63lvd827->mode_gpio = devm_gpiod_get_optional(dev, "mode", GPIOD_OUT_HIGH);

[Severity: Medium]
Will this initialization also cause back-powering via GPIOs on the unpowered
chip?

This configures the mode GPIO to be driven logically HIGH in
thc63lvd827_probe(). Since the chip's regulators are not enabled until later in
thc63lvd827_atomic_pre_enable(), this immediately sources voltage into the
unpowered IC.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005095006.20290-1-francesco@dolcini.it?part=2

  reply	other threads:[~2026-10-05 10:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05  9:50 [PATCH v2 0/4] drm/bridge: Add Thine THC63LVD827 LVDS encoder and 10inch LVDS panel on Colibri iMX7 Francesco Dolcini
2026-10-05  9:50 ` [PATCH v2 1/4] dt-bindings: display: bridge: Add THine THC63LVD827 Francesco Dolcini
2026-10-05 10:52   ` Conor Dooley
2026-10-05  9:50 ` [PATCH v2 2/4] drm/bridge: Add THine THC63LVD827 LVDS encoder Francesco Dolcini
2026-10-05 10:09   ` sashiko-bot [this message]
2026-10-06 15:01     ` Francesco Dolcini
2026-10-05  9:50 ` [PATCH v2 3/4] ARM: dts: imx7d-colibri-emmc: Add Toradex Capacitive Touch Display 10" LVDS Francesco Dolcini
2026-10-05  9:50 ` [PATCH v2 4/4] ARM: dts: imx6ull-colibri-emmc: " Francesco Dolcini

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=20261005100943.1A2711F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=francesco@dolcini.it \
    --cc=imx@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.