Re: [PATCH RFT v2 3/3] arm64: dts: qcom: glymur-crd: Enable USB support

[Abel Vesa]

On 26-02-25 13:16:23, Konrad Dybcio wrote:
> On 2/23/26 4:37 PM, Abel Vesa wrote:
> > From: Wesley Cheng <wesley.cheng@xxxxxxxxxxxxxxxx>
> > 
> > The Qualcomm Glymur Compute Reference Device comes with 3 Type-C ports,
> > one USB Type-A, and a fingerprint reader connected over USB. Each of these
> > 3 Type-C ports are connected to one of the USB combo PHYs and one of the
> > M31 eUSB2 PHYs. The Type-A is connected to the USB Multi-port controller
> > via one of the M31 eUSB2 PHYs and one USB3 UNI PHY. The fingerprint reader
> > is connected to the USB_2 controller. All M31 eUSB2 PHYs have associated
> > eUSB2 to USB 2.0 repeaters, which are either part of SMB2370 PMICs or
> > dedicated NXP PTN3222.
> > 
> > So enable all needed controllers, PHYs and repeaters, while describing
> > their supplies. Also describe the PMIC glink graph for Type-C connectors.
> > 
> > Signed-off-by: Wesley Cheng <wesley.cheng@xxxxxxxxxxxxxxxx>
> > Co-developed-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>
> > ---
> 
> [...]
> 
> > +	pmic-glink {
> > +		compatible = "qcom,glymur-pmic-glink";
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		connector@0 {
> > +			compatible = "usb-c-connector";
> > +			reg = <0>;
> > +
> > +			power-role = "dual";
> 
> there's a newline above here, but not in the corresponding places on
> the nodes of other ports, I think we generally skip the newline here

Will fix.

> 
> [...]
> 
> > +&i2c5 {
> > +	clock-frequency = <400000>;
> > +
> > +	status = "okay";
> > +
> > +	ptn3222_0: redriver@43 {
> > +		compatible = "nxp,ptn3222";
> > +		reg = <0x43>;
> > +
> > +		reset-gpios = <&tlmm 8 GPIO_ACTIVE_LOW>;
> > +
> > +		vdd3v3-supply = <&vreg_l8b_e0_1p50>;
> > +		vdd1v8-supply = <&vreg_l15b_e0_1p8>;
> > +
> > +		#phy-cells = <0>;
> > +	};
> > +
> > +	ptn3222_1: redriver@4f {
> 
> At least on the schematics I have, this one is not present.. but there
> were a lot of variants early on, could you check whether you can 
> communicate with the chip at this address?

Good catch. Only 0x43 and 0x47 exist on the device I have remote access to.

Will drop this one in the next version.

> 
> The rest looks OK

Thanks for reviewing!