Re: [PATCH RFC 06/12] usb: typec: qcom: Add gen1 Type-C port support
From: David Heidelberg
Date: Sat Sep 26 2026 - 10:33:01 EST
On 26/09/2026 16:22, Bryan O'Donoghue wrote:
On 26/09/2026 13:40, David Heidelberg via B4 Relay wrote:
From: David Heidelberg <david@xxxxxxx>
Add a port backend for the first generation of the Qualcomm PMIC Type-C
block, found on PM660 and PMI8998.
On gen1 the Type-C CC logic is part of the charger's USBIN peripheral
(base 0x1300) instead of the standalone Type-C peripheral used by
PM8150B and later PMICs. All Type-C events (CC state change,
tCCDebounce done, VBUS change and error) are signalled through a single
aggregate "type-c-change" interrupt, the handler re-reads TYPEC_STATUS_4
to find out what changed. The PD PHY is register compatible with PM8150B
and is reused as is.
Differences to the PM8150B backend:
- get_cc() returns -EBUSY until the hardware reports tCCDebounce done,
instead of using a software debounce.
- As a source, only the default and 1.5A Rp can be advertised, 3.0A
requests are advertised as 1.5A.
- The PBS workaround of the downstream SMB2 driver (TM_IO_DTEST4_SEL)
is applied on every power role change.
VBUS sourcing is optional and only used when the connector provides
a vbus-supply, as the charger doesn't expose a VBUS regulator yet.
Assisted-by: LLM
Co-developed-by: Alexey Minnekhanov <alexeymin@xxxxxxxxxx>
Signed-off-by: Alexey Minnekhanov <alexeymin@xxxxxxxxxx>
Signed-off-by: David Heidelberg <david@xxxxxxx>
---
drivers/usb/typec/tcpm/qcom/Makefile | 1 +
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 9 +
.../typec/tcpm/qcom/qcom_pmic_typec_port_gen1.c | 605 +++++++++++++++++++++
.../typec/tcpm/qcom/qcom_pmic_typec_port_gen1.h | 15 +
4 files changed, 630 insertions(+)
[...]
+/*
+ * Failure of this workaround write is non-fatal and
+ * we can continue with the role transition.
+ */
+static void gen1_typec_pbs_wa(struct gen1_typec_port *port, bool sink)
+{
+ unsigned int val = sink ? 0 : PBS_CRUDE_SENSOR_ENABLE;
+ int ret;
+
+ ret = regmap_write(port->regmap, port->base +
+ MISC_BASE_OFFSET + TM_IO_DTEST4_SEL, val);
+ if (!ret)
+ return;
Why would the write fail and why wouldn't that be a critical case if the write did fail ?
Heya Bryan,
thanks a lot for reviewing the series. For the rest notes, I'll incorporate that and/or think about it later. Here to quickly answer to this note,
this one quirk is definitely NOT REQUIRED. Originally, I was testing the driver without it on sdm845 devices, and everything worked without it just fine. I ASSUME in some situation or with some devices combination it may come handy, thus likely if it fails, not much usually happens (and clanker was suggesting to port this one from downstream, so I did).
David
[...]