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

[David Heidelberg <david@ixit.cz>]

On 26/09/2026 16:41, Bryan O'Donoghue wrote:
> On 26/09/2026 15:32, David Heidelberg wrote:
>> 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
>>
>> [...]
> 
> I ran this code though an LLM and it is babbling about the "shape" of things to 
> hand you LoL.
> 
> Anyway the pattern matching part flagged this:
> 
> "Write outside the node's reg. base + MISC_BASE_OFFSET + TM_IO_DTEST4_SEL is 
> 0x16e9, the MISC peripheral. 03 declares reg = <USBIN>, <PDPHY> only."
> 
> Worth also verifying.

Yup, I explicitly split the addr into MISC_BASE_OFFSET, as it's pretty much 
outside of this block range (same reason why I haven't sent the vbus patches for 
qcom smbx charger).

Maybe Konrad with more insight can tell more about it. In the Type-C submission 
I can pretty much confidently drop it (if it'll need separate driver) and still 
assure users get expected functionality.

David

> 
> ---
> bod