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

[Robin Snyders <robin@snyders.xyz>]

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.

> Have you tested that this doesn't break the USB-C
> dongles being connected to the device?

Yes. I validated the exact v4 driver on a OnePlus 7T Pro (PM8150B,
6.16-based board tree; the only other change was an
unrelated SLPI debug parameter in qcom_q6v5_pas.c) with TCPM
managing the port, in both plug orientations:

- 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.

- 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