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

[Alexander Koskovich]

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 │
└────────┘

> >
> > Will just drop the sink PDOs from usb_2 and have it be only source to avoid
> > this issue.
> 
> SG as a workaround
> 
> Konrad
> 

Thanks,
Alex