Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Sat, 19 Mar 2022 19:29:50 +0100
Message-Id: <CIO22P1JZY5F.1BYJF4HT2OOUW@otso>
From:   "Luca Weiss" <luca.weiss@fairphone.com>
To:     "Krzysztof Kozlowski" <krzk@kernel.org>,
        <linux-arm-msm@vger.kernel.org>
Cc:     <~postmarketos/upstreaming@lists.sr.ht>,
        <phone-devel@vger.kernel.org>, "Andy Gross" <agross@kernel.org>,
        "Bjorn Andersson" <bjorn.andersson@linaro.org>,
        "Rob Herring" <robh+dt@kernel.org>,
        "Krzysztof Kozlowski" <krzk+dt@kernel.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/6] arm64: dts: qcom: sm6350: Add UFS nodes
References: <20220318183004.858707-1-luca.weiss@fairphone.com>
 <20220318183004.858707-6-luca.weiss@fairphone.com>
 <c88ed4b5-2e44-c3fd-ff2b-b4bee1354765@kernel.org>
In-Reply-To: <c88ed4b5-2e44-c3fd-ff2b-b4bee1354765@kernel.org>
Precedence: bulk

Hi Krzysztof,

On Sat Mar 19, 2022 at 3:43 PM CET, Krzysztof Kozlowski wrote:
> On 18/03/2022 19:30, Luca Weiss wrote:
> > Add the necessary nodes for UFS and its PHY.
> >=20
> > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > ---
> >  arch/arm64/boot/dts/qcom/sm6350.dtsi | 79 ++++++++++++++++++++++++++++
> >  1 file changed, 79 insertions(+)
> >=20
> > diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts=
/qcom/sm6350.dtsi
> > index d7c9edff19f7..c5c93b6bcd2a 100644
> > --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
> > @@ -541,6 +541,85 @@ uart2: serial@98c000 {
> >  			};
> >  		};
> > =20
> > +		ufs_mem_hc: ufshc@1d84000 {
>
> Generic node name, so ufs.

With the node name changes UFS doesn't probe anymore.

[    1.893762] ufshcd-qcom 1d84000.ufs: ufshcd_variant_hba_init: variant qc=
om init failed err -19
[    1.902674] ufshcd-qcom 1d84000.ufs: Initialization failed
[    1.908391] ufshcd-qcom 1d84000.ufs: ufshcd_pltfrm_init() failed -19

I didn't debug this in detail but it's likely from the
androidboot.bootdevice=3D1d84000.ufshc parameter in cmdline that
ufs-qcom.c uses to fail probe with -ENODEV for all UFS other than the
selected one. Not sure why this behavior exists in mainline (didn't look
into this either).

This cmdline parameter (among many others) is added by the stock
bootloader and as far as I know there's no way to turn that off.


>
> > +			compatible =3D "qcom,sm6350-ufshc", "qcom,ufshc",
> > +				     "jedec,ufs-2.0";
> > +			reg =3D <0 0x01d84000 0 0x3000>,
> > +			      <0 0x01d90000 0 0x8000>;
> > +			reg-names =3D "std", "ice";
> > +			interrupts =3D <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> > +			phys =3D <&ufs_mem_phy_lanes>;
> > +			phy-names =3D "ufsphy";
> > +			lanes-per-direction =3D <2>;
> > +			#reset-cells =3D <1>;
> > +			resets =3D <&gcc GCC_UFS_PHY_BCR>;
> > +			reset-names =3D "rst";
> > +
> > +			power-domains =3D <&gcc UFS_PHY_GDSC>;
> > +
> > +			iommus =3D <&apps_smmu 0x80 0x0>;
> > +
> > +			clock-names =3D
>
> Drop unneeded blank line, start just after '=3D' and align next elements
> with it.

Sure.

>
> > +				"core_clk",
> > +				"bus_aggr_clk",
> > +				"iface_clk",
> > +				"core_clk_unipro",
> > +				"core_clk_ice",
> > +				"ref_clk",
> > +				"tx_lane0_sync_clk",
> > +				"rx_lane0_sync_clk",
> > +				"rx_lane1_sync_clk";
> > +			clocks =3D
>
> The same.

Sure. I also adjusted the clock name/order to match the bindings (thanks
for spotting the problems there!)

Regards
Luca

>
>
> Best regards,
> Krzysztof