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

[Konrad Dybcio]

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

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	
}

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