From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9441C1C84BB for ; Sun, 19 Jul 2026 18:24:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784485443; cv=none; b=LxVGcJ2sSkIVvGxruQWL0NlUAndQWGP+OHnzsLa/iHo4NfLcx7e1qlNB0URfpZioeR2B7i2L4rRMwA2wFxuHftAhQaVXYXCKMonw1IM1aFz5dD1MAq2Z8ywMlGUZbQlUkUFpmS8nhob6t7s4uC5ao+cAasFeHniEsUw9875/KZs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784485443; c=relaxed/simple; bh=JVGxk8qWySW3SBk9XQcniWcmTES3jnchmeRIto6lQOo=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=cMMwLdoLioK3xAGQ9E7U2vgX1VGJzzHSDIleqveW9YC+OJ4bQMXKg5Q6dzZBk0pBsCrO6SDmtCPD6D8AqwBJiF0/SrOpj9UVnb1PfVwPKB3wd9tjz9diI9hgWRNMlWI2PAJuFSZQv9KSSoOREx+Sq9DAI7Us2995RAoYjfLFoJI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Agl2IC2G; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Agl2IC2G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D720A1F000E9; Sun, 19 Jul 2026 18:24:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784485442; bh=4/u4muwjCf9MY79QdUd9mgzIgxbmA0w40/V3H4Xnx/o=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Agl2IC2G5zMJVWnehthnRUxyQmxLJIU8sow1s6Gj5BhEMKb+QHxqayf+DlO0djp6g I7+eJOrb9g8o2Cfn72lT9e0J9aCF4VjxjGtYAupy0QQjEj6uAnKdbG13JUrQAvKJL0 BHdqnYPdzORRgNgeLPGmpZsH2R6OhMxsbjvg0nnTyjJbS8DFXdGmkEPGhb4Gg4f5nM OfWoPlbHgQyU/7s6xcgZG/mEJAWHnSl5Vt870QrA0zCtiubIjLFnXMD/nkyHqRWu7A UtyemAghKvzpeB7pxGsItKbW+GJ0EgQVo8erTglZsh2pshpVWM4b4Oo5qCImKzxwal dz+L/0dP61FJA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v5 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras Reply-To: sashiko-reviews@lists.linux.dev To: "David Heidelberg" Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org In-Reply-To: <20260719-pixel3-camera-v5-1-99593f1bd8ec@ixit.cz> References: <20260719-pixel3-camera-v5-0-99593f1bd8ec@ixit.cz> <20260719-pixel3-camera-v5-1-99593f1bd8ec@ixit.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Jul 2026 18:24:01 +0000 Message-Id: <20260719182401.D720A1F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [High] Pinctrl for MCLK2 is attached to the camss consumer, causing a pro= be deadlock that breaks camera initialization. - [Medium] Incorrect pinctrl sleep state override for I2C bus causes power = leakage and configuration conflict. -- --- Patch [1]: [PATCH v5 1/2] arm64: dts: qcom: sdm845-google: Add dual fro= nt IMX355 cameras --- commit 650af867be78a11fabbd3346603a6fc8f7cb758f Author: David Heidelberg arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras The Pixel 3 features two front-facing Sony IMX355 sensors with different focal lengths (standard and wide-angle). Sensors are connected via CSIPHY port 1 and 2 and controlled over CCI I2C1, using MCLK2 as the clock source. This enables support for the dual front camera configuration. > diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/ar= m64/boot/dts/qcom/sdm845-google-common.dtsi > index 9368fd6b87515..cb5c261802bc9 100644 > --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi > +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi [ ... ] > @@ -351,6 +389,52 @@ vreg_s3c_0p6: smps3 { > }; > }; > =20 > +&camss { > + vdda-phy-supply =3D <&vreg_l1a_0p875>; > + vdda-pll-supply =3D <&vreg_l26a_1p2>; > + > + /* > + * MCLK2 (GPIO15) is shared between both front camera sensors. > + * The clock is generated by CAMCC, therefore the pin is > + * configured here rather than in individual sensor nodes. > + */ > + pinctrl-0 =3D <&cam_mclk2_default>; > + pinctrl-1 =3D <&cam_mclk2_sleep>; > + pinctrl-names =3D "default", "sleep"; [Severity: High] Will this cause a probe deadlock that breaks camera initialization? Since fw_devlink parses the remote-endpoint properties, it establishes that camss depends on the imx355 sensors, meaning imx355 will probe first. During the imx355 probe, it requests and enables MCLK2. However, because the pinctrl for MCLK2 is attached to the camss consumer rather than the provider (camcc) or a dedicated gpio-gate-clock node, the physical pin (GPIO15) won't be configured to output the clock until camss probes. Without the clock active, will the imx355 sensor fail to respond to the I2C read for its CHIP_ID and fail to probe entirely? [ ... ] > +}; > + > +&cci0_sleep { > + /* bus has external pull-up, don't pull down */ > + bias-disable; > +}; [Severity: Medium] Is this targeting the correct CCI bus? The commit message states the cameras are controlled over CCI I2C1, which uses cci1_sleep. By overriding cci0_sleep instead, does this leave the I2C lines for the cameras pulled down against their external pull-ups during sleep, causing a continuous power leak? Additionally, without using /delete-property/ bias-pull-down;, won't cci0_sleep incorrectly contain both bias-disable and bias-pull-down conflicting settings? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260719-pixel3-cam= era-v5-0-99593f1bd8ec@ixit.cz?part=3D1