All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Srinivas Kandagatla" <srinivas.kandagatla@oss.qualcomm.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 2/3] arm64: dts: qcom: Add Lenovo ThinkPad T14s Gen 7
Date: Mon, 28 Sep 2026 15:04:04 +0000	[thread overview]
Message-ID: <20260928150404.D18611F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260928145122.1337186-3-srinivas.kandagatla@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dts: Reset GPIO conflict between ptn3222_1 and ptn3222_cam
- [Medium] dts: Panel power sequencing issue due to premature backlight enable
--

commit c99537659e637d229456f818bb7c8fc0b3d7fcf3
Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>

arm64: dts: qcom: Add Lenovo ThinkPad T14s Gen 7
    
Introduce a device tree for the Mahua-based Lenovo ThinkPad T14s Gen 7,
a Snapdragon X2 Elite laptop.  It follows the Qualcomm Glymur reference
design used by mahua-crd.

> diff --git a/arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts b/arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts
> new file mode 100644
> index 0000000000000..26d6d8285e040
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts
> @@ -0,0 +1,1272 @@
[ ... ]
> +	ptn3222_1: redriver@4b {
> +		compatible = "nxp,ptn3222";
> +		reg = <0x4b>;
> +
> +		reset-gpios = <&tlmm 184 GPIO_ACTIVE_LOW>;
> +
> +		vdd3v3-supply = <&vreg_l8b_e0_3p3>;
> +		vdd1v8-supply = <&vreg_l15b_e0_1p8>;
> +
> +		#phy-cells = <0>;
> +	};
> +
> +	ptn3222_cam: redriver@47 {
> +		compatible = "nxp,ptn3222";
> +		reg = <0x47>;
> +
> +		reset-gpios = <&tlmm 184 GPIO_ACTIVE_LOW>;

[Severity: High]
Could this GPIO assignment conflict with ptn3222_1 above?

The ptn3222 driver requests the reset GPIO exclusively during probe via
devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH). Because the GPIO
subsystem prevents sharing an exclusive GPIO by default, assigning the same
GPIO to both redrivers could cause one of them to deterministically fail to
probe with a -EBUSY error.

> +
> +		vdd3v3-supply = <&vreg_l8b_e0_3p3>;
> +		vdd1v8-supply = <&vreg_l15b_e0_1p8>;
> +
> +		#phy-cells = <0>;
> +	};
[ ... ]
> +	aux-bus {
> +		panel {
> +			compatible = "edp-panel";
> +			enable-gpios = <&tlmm 18 GPIO_ACTIVE_HIGH>;
> +			power-supply = <&vreg_edp_3p3>;
> +
> +			pinctrl-0 = <&edp_bl_en>;
> +			pinctrl-names = "default";

[Severity: Medium]
Will this cause visual artifacts during boot or resume?

It appears the backlight enable GPIO (tlmm 18) is passed here as the panel's
logic power enable. The panel-edp driver asserts enable-gpios in
panel_edp_prepare_once() before the eDP link is trained and valid video data
is streaming. Bypassing proper eDP DPCD and backlight sequencing could turn
the backlight on prematurely.

> +
> +			port {
> +				edp_panel_in: endpoint {
> +					remote-endpoint = <&mdss_dp3_out>;
> +				};
> +			};
> +		};
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928145122.1337186-1-srinivas.kandagatla@oss.qualcomm.com?part=2

  reply	other threads:[~2026-09-28 15:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 14:51 [PATCH v3 0/3] arm64: dts: qcom: Lenovo ThinkPad T14s Gen 7 (Mahua) support Srinivas Kandagatla
2026-09-28 14:51 ` [PATCH v3 1/3] dt-bindings: arm: qcom: add Lenovo ThinkPad T14s Gen 7 (Mahua) Srinivas Kandagatla
2026-09-28 21:13   ` Rob Herring (Arm)
2026-09-28 14:51 ` [PATCH v3 2/3] arm64: dts: qcom: Add Lenovo ThinkPad T14s Gen 7 Srinivas Kandagatla
2026-09-28 15:04   ` sashiko-bot [this message]
2026-09-28 21:07     ` Srinivas Kandagatla
2026-09-28 14:51 ` [PATCH v3 3/3] firmware: qcom: scm: Allow QSEECOM on " Srinivas Kandagatla
2026-09-29 22:47 ` (subset) [PATCH v3 0/3] arm64: dts: qcom: Lenovo ThinkPad T14s Gen 7 (Mahua) support Bjorn Andersson

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=20260928150404.D18611F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=srinivas.kandagatla@oss.qualcomm.com \
    /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.