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

[Konrad Dybcio]

On 3/18/26 12:56 PM, Alexander Koskovich wrote:
> On Wednesday, March 18th, 2026 at 7:29 AM, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>  
>>>>> +		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
>>
> 
> Both USB-C connectors have their own OVP chip, and both OVP outputs feed into
> the same USB_IN rail on the PM8150B, there's no switch or mux on the power path
> just the OVP chips that are always passing through. The GPIOs on the OVPs are
> just for notification of what one is providing VBUS into USB_IN.
> 
> Here's a diagram from my understanding of the power setup:
> ┌────────┐
> │ USB-C1 │
> └───┬────┘
>     │
> ┌───┴───┐
> │  OVP  ├──── vbus-detect (GPIO 60)
> └───┬───┘
>     │
>     ├──── PM8150B (USB_IN)
>     │
>     ├──── NXP PCA9468 (direct charger)
>     │
> ┌───┴───┐
> │  OVP  ├──── vbus-detect (GPIO 13)
> └───┬───┘
>     │
> ┌───┴────┐
> │ USB-C2 │
> └────────┘

Hmm.. from a DT standpoint, I think a fair representation would be to have
the battery node track the two possible power inputs, but I have no clue
whether this is something that Linux (or binings) supports today

Konrad