Re: [PATCH RFC 06/12] usb: typec: qcom: Add gen1 Type-C port support

[David Heidelberg <david@ixit.cz>]

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@ixit.cz>
>>
>> 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@minlexx.ru>
>> Signed-off-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
>> ---
>>   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

[...]