Re: [PATCH v3 2/2] power: supply: qcom_smbx: add SMB5 support

[Dmitry Baryshkov]

On Sun, Oct 18, 2026 at 08:44:59PM +0200, Robin Snyders wrote:
> Hi Dmitry,
> 
> Sorry for the long delay in getting back to you on this.
> 
> On Thu, Aug 13, 2026 at 06:52:24PM +0300, Dmitry Baryshkov wrote:
> > I remember that in SMB2 case the TCPM and charger drivers were
> > programming the registers from the same block. Is there no such conflict
> > on the SMB5 platforms?
> 
> On PM8150B the register sets are disjoint. The charger node sits at
> 0x1000, the dedicated Type-C port at 0x1500 and the PD PHY at 0x1700.
> With SMB5, qcom_smbx only writes the charger core (0x1042, 0x1061,
> 0x1070), DCDC (0x1108, 0x110b), USB input / BC1.2 (0x1340-0x1380) and
> the watchdog/AICL timer (0x1651-0x1661) blocks. qcom_pmic_typec writes
> are all in 0x1544-0x1560, and the PD PHY stays in its 0x1700 block.
> 
> The one name that looks like an overlap is TYPE_C_CFG, but on SMB5
> that is offset 0x358, i.e. 0x1358 in the USB input peripheral, and not
> the Type-C port register at 0x1544. The driver only clears
> APSD_START_ON_CC_BIT there, so that BC1.2 detection is not started
> directly from CC state while TCPM owns the port.
> 
> By design, the SMB5 path also leaves Type-C power role and VBUS control
> to TCPM and the qcom_usb_vbus regulator. It does not touch OTG/VBUS
> boost, and it only clears the HVDCP modes so stale firmware settings
> cannot raise VBUS.

This sounds good, but also a bit strange. As far as I remember, most of
the QuickCharge protocols require extra control during negotiation.
Basically, I'm afraid, that this way we can get the basic charging to
work, but not any of the quicker charging protocols.

> 
> > Have you tested that this doesn't break the USB-C
> > dongles being connected to the device?
> 
> - Powered dock: the phone became data host and power sink (USB PD,
>   usb_vbus disabled). The USB 2/3 hubs, an RTL8153 Ethernet adapter
>   and a mass storage device enumerated, and a 64 MiB read gave the
>   same hash every time. The charger stayed online, health Good.

Could you please check in the debugfs in TCPM log that you can actually
see USB-C negotiation happening over the wire? The same applies to the
next testing point, the unpowered dock.

> 
> - The same dock with its external power removed: the phone stayed
>   data host and switched to power source, with usb_vbus enabled. The
>   hubs, Ethernet adapter and storage re-enumerated and worked, and
>   the storage hash matched. The SMB5 charger correctly reported
>   offline/discharging.
> 
> - Then back to a PC cable without rebooting: device/sink roles
>   returned, usb_vbus was disabled, USB gadget networking and SSH
>   worked again, and the charger resumed charging at its 500 mA
>   limit.
> 
> None of these transitions produced an oops, lockdep splat, UVLO, OCP
> or OVP event. Ethernet traffic (no cable at hand) and visual
> DisplayPort output were not part of that run.
> 
> I'll repeat this on the exact v5 tree before sending it, and summarize
> the register ownership and these results in the v5 changelog.
> 
> Thanks,
> Robin

-- 
With best wishes
Dmitry