Re: [PATCH v3 2/2] arm64: dts: qcom: sm8250-asus-obiwan: Add ASUS ROG Phone 3

[Dmitry Baryshkov]

On Wed, Mar 18, 2026 at 12:29:37PM +0100, Konrad Dybcio wrote:
> On 3/18/26 12:14 PM, Alexander Koskovich wrote:
> > On Wednesday, March 18th, 2026 at 6:28 AM, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> > 
> >>> +	/*
> >>> +	 * There are also ER & EVB boards, but those have meaningful hardware
> >>> +	 * differences that make them not compatible with this devicetree.
> >>> +	 */
> >>> +	qcom,board-id = <31 0>, /* ER2 */
> >>> +			<40 0>, /* PR */
> >>> +			<41 0>, /* PR2 */
> >>> +			<50 0>; /* MP */
> >>
> >> I would guesstimate MP is Mass Production and everything before that is
> >> engineering samples.. perhaps that doesn't hurt - maybe some curious Asus
> >> engineer swings by one day!
> > 
> > Actually the unit I have is 'PR', it's one I got from ASUS when they were still
> > sending out phones to developers. I guess the units they shipped out were preprod.
> 
> Oh, nice!
> 
> Maybe 'public relations'..
> 
> 
> >>> +		source-pdos = <PDO_FIXED(5000, 900,
> >>> +					 PDO_FIXED_DUAL_ROLE |
> >>> +					 PDO_FIXED_USB_COMM |
> >>> +					 PDO_FIXED_DATA_SWAP)>;
> >>> +
> >>> +		sink-pdos = <PDO_FIXED(5000, 3000,
> >>> +				       PDO_FIXED_DUAL_ROLE |
> >>> +				       PDO_FIXED_USB_COMM |
> >>> +				       PDO_FIXED_DATA_SWAP)
> >>> +			     PDO_FIXED(9000, 3000, 0)
> >>> +			     PDO_FIXED(12000, 2250, 0)>;
> >>
> >> Both ports have the same PDOs - will this kaboom if you plug in two chargers?
> > 
> > Good catch, from what I can see there is zero hardware isolation. Downstream
> > prevents dual sink by only allowing one port to negotiate sink at a time (seems
> > to always prefer usb_1 if both are plugged in, guessing because its used for
> > the dock), but there is no upstream mechanism to handle this as far as I know
> > (not sure if this could even be done cleanly as it'd require cooperation
> > between pm8150b_typec and rt1715).
> 
> Could you please remind me how the two were connected? Maybe we can work
> something out. Sounds like it would make sense for the two to have *some*
> sort of relationship described
> 
> > 
> > Will just drop the sink PDOs from usb_2 and have it be only source to avoid
> > this issue.
> 
> SG as a workaround
> >>> +&usb_2 {
> >>> +	pinctrl-0 = <&rt1715_mux_en>, <&usb2_mux_en>;
> >>> +	pinctrl-names = "default";
> >>> +
> >>> +	/*
> >>> +	 * Disable USB3 clock requirement as the bottom port only supports USB2.
> >>> +	 * The USB3 lanes are routed through the pogo connector on this board for
> >>> +	 * use with accessories, so will need to revisit this when we start to add
> >>> +	 * support for those.
> >>> +	 */
> >>> +	qcom,select-utmi-as-pipe-clk;
> >>
> >> So, is that right?
> >>
> >>                                   ┌───────┐
> >>                                   │ POGO  │
> >>                                   └──┬──┬─┘
> >>                    superspeed        │  │
> >>        ┌─────────────────────────────┘  │
> >>        │                                │
> >> ┌──────┼─┐      highspeed               │
> >> │ DWC3_2 ┼─────────────────────┐   ┌────┴──┐
> >> └────────┘                     └───┤  MUX  ┼───────PM8150_GPIO9
> >>                  ┌─────────┐       └──┬────┘
> >>                  │ GPIO170 │          │
> >>                  └─────────┘          │
> >>                       │               │
> >> ┌────────┐ RXTX   ┌───┴──┐        ┌───┴──┐
> >> │ UART   ┼────────│ MUX  ┼────────┤USB-C2│
> >> └────────┘        └──┬───┘        └──────┘
> >>                      │
> >>                      ▼
> >>                     GND
> > 
> > I misspoke in v3, UART is not controlled via a mux it's just a gate. Was
> > looking at the board previously and it seemed it either went to test points on
> > the board, or USB. But the enable GPIO controls both. Have it renamed in v4
> > staging atm.
> > 
> > But yeah that is accurate otherwise wrt the USB 2 mux.
> 
> Okay.. I don't know whether we have infra to handle it today (+Dmitry?)
> but generally we'd need something like

No, we don't. We have generic muxes under bindings/mux.

> 
> usb-mux {
> 	select-gpios = <&tlmm foo bar>;
> 	// sense it via some notification?
> 
> 	ports {
> 		// conn to usb_2_hs
> 		// conn to type-c
> 		// conn to pogo pin connector
> 	};
> };
> 
> rt1715 {
> 	connector {
> 		// mux conn
> 	}
> }
> 
> pogo-pins-connector {
> 	// mux conn	
> }

I tried designing it as something following mux-controller, but it
doesn't seem to fit. So yeah... This might be the best way to implement
it. But something as simple as this might also work:

mux: mux-controller {
	compatible = "gpio-mux";
};

rt1715-connector {
	mux = <&mux 0>;
	ports {
		// hs
	};
};

pogo-connector {
	mux = <&mux 1>;
	ports {
		// hs
	};
};

dwc3 {
	ports {
		port@0 {
			// endpoint@0 to rt1715
			// endpoint@1 to pogo
		};
	};
};

Or even:


mux: mux-controller {
	compatible = "gpio-mux";
};

rt1715-connector {
	ports {
		// hs
	};
};

pogo-connector {
	ports {
		// hs
	};
};

dwc3 {
	ports {
		port@0 {
			mux = <&mux>;
			// endpoint@0 to rt1715
			// endpoint@1 to pogo
		};
	};
};

> 
> there was a similar attempt (I bumped it up.. maybe it'll be merged soon)
> at describing a pogo pin connector, so part of that may come in useful:
> 
> https://lore.kernel.org/all/20250225223038.879614-2-swboyd@xxxxxxxxxxxx/
> 
> but in any case, that's a song of the future..
> 
> Konrad

-- 
With best wishes
Dmitry